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I.  INTRODUCTION 


A.  INTRODUCTION 

In  2014  cyber  attacks  on  critical  infrastructure  are  expected  to  increase 
significantly  and  consequently  cause  security  expenditures  to  reach  a  peak  of  $86  billion 
(Rivera,  2013).  Even  after  all  the  attention  devoted  to  this  threat,  cyber-related  problems 
do  not  seem  to  be  resolved.  According  to  the  task  force  report  of  the  Defense  Science 
Board,  the  advanced  cyber  threat  the  Department  of  Defense  (DoD)  faces  is  too 
prevalent,  and  critical  IT  structures  may  stop  functioning  in  case  of  a  sophisticated  and 
well-resourced  attack  vector  (Kaminski,  2012).  This  threat  becomes  even  more  disturbing 
when  we  realize  that  a  malicious  user  can  cripple  the  Unified  Threat  Management  System 
(10  million  lines  of  code)  with  a  malware  (125  lines  of  code)  (Dean,  2013). 

Being  under  the  cyber  threat  of  its  opponents,  the  DoD  has  taken  the  necessary 
precautions  in  different  areas.  One  of  those  areas  is  the  fonnal  verification  of  military 
software,  which  is  used  to  process  classified  information.  One  to  five  bugs  are  found  in  a 
thousand  lines  of  code  of  military  software,  and  most  of  them  are  related  to  security 
vulnerabilities. 

Currently  formal  verification  is  performed  manually  by  very  specialized  engineers 
and  this  is  a  very  expensive  process  (Dean,  2013).  The  Defense  Advanced  Research 
Projects  Agency  (DARPA)  initiated  a  project  to  lower  the  costs  of  the  verification 
process  and  increase  the  efficiency  levels  by  harnessing  the  power  of  a  crowd.  Crowd 
Sourced  Fonnal  Verification  (CSFV)  aims  to  perfonn  the  necessary  software  verification 
by  creating  computer  games,  which  are  fun  to  play.  The  goal  is  to  make  the  crowd  play 
the  games  and  have  the  military  software  verified  in  the  background.  Even  though  it 
sounds  innovative  to  use  the  crowd  to  solve  a  problem,  it  is  not  a  new  concept. 
Crowdsourcing  was  used  by  DARPA  before  to  design  a  next-generation  combat  vehicle 
and  to  reconstruct  shredded  documents,  such  as  those  found  after  military  engagements 
(Montalbano,  2011). 
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DARPA  plans  to  run  its  CSFV  systems  on  the  Internet — possibly  using  cloud 
infrastructure  (Dean,  2013).  By  using  Amazon  Compute  Cloud  (EC2)  systems,  DARPA 
will  use  ordinary  people  and  make  them  play  the  games,  which  will  enable  the  software 
verification  with  the  help  of  complex  algorithms. 

This  thesis  aims  to  design  and  prototype  a  secure  network  for  CSFV  systems,  and 
this  network  will  be  run  on  a  limited  access  intranet  such  as  the  Defense  Research  and 
Engineering  Network  (DREN),  whereas  DARPA’s  initial  gaming  environment  will  exist 
on  the  Internet,  open  to  everyone. 

B.  THE  RESEARCH  PROBLEM 

1.  Problem  Statement 

DARPA’s  CSFV  systems  are  designed  to  reside  on  the  Internet,  and  they 
welcome  anyone  to  log  on  and  play  the  games.  However,  there  is  currently  no  network 
architecture  to  run  the  games  on  classified  intranets  such  as  DREN,  the  Non-classified 
Internet  Protocol  Router  Network  (NIPRNET)  or  the  Secret  Internet  Protocol  Router 
Network  (SIPRNET). 

2.  Purpose  Statement 

The  purpose  of  this  thesis  will  be  to  design  and  prototype  a  secure  network 
architecture  for  implementing  Crowd  Sourced  Formal  Verification  methods  on 
classified/unclassified  networks. 

C.  RESEARCH  QUESTIONS  AND  HYPOTHESIS 

In  this  thesis  these  research  questions  will  be  answered  and  explained: 

1 .  What  are  the  common  security  threats  and  solutions  for  securing  enterprise 
network  resources? 

2.  What  are  the  key  benefits  of  virtualization,  and  how  can  virtualization  be 
implemented  on  DREN  while  meeting  security  requirements? 

3.  What  are  the  possible  security  concerns  of  cloud  computing? 

4.  What  are  the  unique  security  challenges  for  deploying  CSFV  on  DREN? 
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D.  THESIS  ORGANIZATION 

Chapter  I:  “Introduction”  (Introductory  information  about  formal  verification 
issues  and  the  need  for  efficient  software  verification) 

Chapter  II:  “Background”  (Review  of  definitions  and  details  of  concepts  related 
to  CSFV  such  as  crowdsourcing,  cloud  computing,  virtualization  and  enterprise  network 
security) 

Chapter  III:  “Network  Design”  (Design  of  optimally  most  secure  network  in 
regard  to  the  potential  security  vulnerabilities/threats  specifically  for  CSFV  networks) 

Chapter  IV :  “Implementation”  (Creation  of  the  CSFV  network  prototype) 

Chapter  V:  “Conclusion”  (Summary,  future  work  and  recommendations) 
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II.  BACKGROUND 


A.  INTRODUCTION 

This  chapter  will  summarize  the  core  concepts  that  will  be  reviewed  in  this  thesis. 
In  the  following  section  basic  infonnation  about  crowdsourcing  will  be  presented, 
including  its  history,  current  use,  and  vast  benefits.  Sections  C  and  D  will  explain  two 
necessary  platforms  for  CSFV  systems,  which  are  virtualization  and  cloud-computing. 
Finally  this  chapter  concludes  with  information  about  the  current  cyber  security  threats 
pertaining  to  CSFV  networks. 

B.  CROWDSOURCING 

Crowdsourcing  provides  a  workspace  to  be  used  for  a  large  scale  of  activities. 
These  activities  vary  from  journalism  to  image  indexing  and  from  language  translation  to 
entertainment  (Howe,  2009).  Crowdsourcing  is  the  outcome  of  two  words:  “crowd”  and 
“outsourcing”  and  is  meant  to  accomplish  something  with  the  help  of  untrained,  ordinary 
people,  rather  than  professionals  and  experienced  employees.  The  crowd  may  be  drawn 
from  either  a  large  or  small  population.  The  activity,  which  is  done  by  the  crowd  may 
help  for  projects  such  as  designing  a  task,  developing  a  technology,  solving  an  algorithm 
or  classifying,  collecting  or  analyzing  large  amounts  of  data  (Bell,  2010).  Nowadays 
typical  examples  of  crowdsourcing  are  created  online,  but  the  first  examples  of 
crowdsourcing  were  quite  different.  Organizations  have  leveraged  crowdsourcing 
solutions  throughout  history. 

1.  A  Brief  History  of  Crowdsourcing 

The  history  of  crowdsourcing  dates  back  to  1714  when  the  Longitude  Contest  was 
organized  by  the  English  government.  The  purpose  of  this  contest  was  to  enable  the 
government  to  find  a  prototype  of  a  navigation  device,  which  might  even  be  developed 
by  a  common  citizen,  to  help  sailors  navigate  easily  (Lynch,  2010).  Another  early 
example  is  the  Toyota  Logo  Contest  in  1936.  Twenty-seven  thousand  people  attended 
this  event,  and  the  best  design  created  by  someone  in  this  crowd  was  chosen  to  be  the 
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Toyota  Logo.  In  1955  the  Sydney  Opera  House  was  also  designed  and  built  as  a  result  of 
a  public  contest,  which  encouraged  ordinary  people  from  32  countries  to  help  this  design 
project  (Lynch,  2010). 

2.  Current  Crowdsourcing  Activities 

Crowdsourcing  provides  opportunities  to  solve  the  chronic  problems  worldwide 
that  have  been  waiting  to  be  solved  for  years.  The  diverse  base  of  knowledge  and  abilities 
is  unlimited  in  a  crowd.  The  technique  of  crowdsourcing  would  match  this  diverse  base 
with  the  needs  of  people  using  this  technique  (Howe,  2009).  Currently  crowdsourcing 
activities  around  the  world  are  increasing  rapidly.  Most  IT  companies  are  handing  their 
technical  support  elements  to  forums  in  which  users  share  knowledge.  In  journalism, 
sector  leaders  like  Reuters  and  the  BBC  are  increasingly  choosing  public  resources  to 
crowdsource  important  work,  such  as  investigating  government  wrongdoings  or  reports 
about  local  events.  In  March  2009  public  opinion  was  largely  gathered  and  analyzed 
through  the  White  House  website,  and  those  results  greatly  affected  political 
decisions  (Howe,  2009). 

Another  area  of  crowdsourcing  is  the  freelance  sector.  Although  it  is  a  local 
Chinese  firm,  the  freelancing  website  Zhubajie.com  has  more  than  seven  million 
subscribers,  and  it  is  still  growing  (Lynch,  2012).  Such  growth  is  hardly  surprising.  It  is  a 
fact  that  a  large  population  helps  a  lot  in  crowdsourcing.  In  the  following  subsections 
some  globally  known  crowdsourcing  examples  will  be  presented  along  with  some  local 
examples. 


3.  Linux  Kernel 

Open  source  software  development  projects  inherently  allow  users  to  see,  change 
or  add  code  freely  to  the  already  developed  software.  In  the  1990s  this  open  source 
development  environment  enabled  the  creation  of  an  important  product,  Linux.  Its 
creator,  Linus  Torvalds,  declared  that  the  operating  system  that  he  had  developed  was 
open  to  any  critics,  and  he  was  looking  for  others  who  could  help  improve  it  (Howe, 
2009).  By  getting  the  crowd’s  help,  today  Linux  is  in  use  everywhere — from 
supercomputers  to  hand-held  devices. 
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4. 


reCAPTCHA 


Originated  at  Carnegie  Mellon  University  by  Professor  Luis  Von  Ahn, 
reCAPTHCA  is  designed  to  digitize  the  text  in  the  books.  It  has  been  used  to  digitize  The 
New  York  Times  archives.  Another  use  of  reCAPTCHA  is  to  protect  websites  from  bots 
that  are  designed  to  infiltrate  the  restricted  areas  in  the  network  (Bell,  2010). 

reCAPTCHA  provides  websites  with  the  images  of  words  that  bot  software  is 
unable  to  read.  The  registered  websites  help  verify  these  images  and  present  them  as 
CAPTCHA  words,  and  the  words  are  sent  to  digitization  projects.  This  service  is 
calculated  to  provide  12,000  man-hours  per  day  of  free  labor  (Bell,  2010).  Popular 
websites  such  as  Facebook,  Twitter  and  Ticketmaster  are  effectively  using  this  service  in 
the  customer  validation  process  (Bell,  2010). 

5.  Games  with  a  Purpose  (GWAP)  Project 

Another  application  in  the  vast  area  of  crowdsourcing  is  using  simple  games  to 
achieve  a  purpose  that  is  much  more  valuable  than  just  relaxing.  Because  billions  of 
people  including  children  are  interested  in  games,  and  maybe  millions  of  them  are 
spending  several  hours  daily  playing  games,  scientists  thought  that  these  valuable  hours 
could  be  used  beneficially  in  parallel  with  the  fun  part.  Carnegie  Mellon  University 
Professor  Luis  Von  Ahn  created  the  GWAP  project  to  use  game  playing  hours  for  a 
scientifically  valuable  purpose,  such  as  Internet  image  indexing,  monitoring  security 
cameras  and  perfonning  language  translation  (Ahn,  2006).  Other  possible  application 
areas  could  be  IT  security,  Internet  accessibility,  adult  content  filtering,  and  web  search 
(Ahn,  2006).  The  main  idea  behind  this  project  is  to  have  people  play  games  and  use  the 
results  of  the  games  for  another  purpose.  One  of  the  most  popular  of  these  games,  the 
ESP  game  designed  by  Ahn,  is  designed  for  two  players.  These  players  must  agree  on  the 
best  word  that  represents  the  image  presented  to  them.  They  do  this  without  knowing  that 
they  are  seeing  the  same  image  (Bell,  2010). 

The  concept  of  playing  games  is  applied  to  other  areas  as  well.  A  game  such  as 
“Foldit,”  which  was  designed  by  researchers  from  the  University  of  Washington,  allows 
users  to  play  with  protein-like  structures  by  folding  and  unfolding  them.  When  the 
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protein  structure  is  modified  games  scores  are  automatically  recorded  with  regard  to  the 
success  level  of  how  accurate  the  folding  is  (Bell,  2010). 

6.  Verification  Games:  Making  Verification  Fun 

This  project  is  directly  related  to  the  CSFV  concept,  and  it  aims  to  make  people 
play  games  as  a  part  of  the  CSFV  project.  Ernst  (2012)  investigated  ways  to  lower  the 
costs  of  software  verification  by  developing  game-playing-based  verification  systems.  In 
his  latest  work  he  introduces  and  explains  the  technique  he  used  in  the  game  “Pipe  Jam,” 
which  is  used  to  map  a  software  and  to  correct  potential  problems  in  that  software. 

His  game  is  comprised  of  boards,  levels  and  worlds  in  which  the  gamer  plays  with 
pipes  that  are  linked  to  each  other.  The  gamer  tries  to  pass  a  ball  into  different  sizes  of 
pipes.  The  width  of  a  pipe  represents  the  type  of  variable  that  the  pipe  represents.  A  wide 
pipe  stands  for  a  variable  that  is  permitted  to  contain  a  “null”  value  whereas  a  narrow 
pipe  represents  a  variable  that  is  guaranteed  to  be  non-null. 

As  with  the  general  concept  of  CSFV,  a  gamer  does  not  have  to  know  anything 
about  the  software  he  helps  to  verify.  Gamers  do  not  have  to  have  confidentiality 
privileges,  and  they  can  be  anyone  from  public. 

The  Pipe  Jam  game  is  analogous  to  the  dataflow  network  for  a  program.  It  maps 
the  source  code’s  type  flow  properties  into  a  network  of  pipes.  Essentially,  this  system 
converts  the  software  into  a  game  that  can  be  played  by  ordinary  people.  After  the  player 
finishes  a  portion  of  the  game  the  final  board  configurations  can  be  translated  into  a  proof 
of  correctness  for  the  original  program  (Ernst,  2012). 

a.  Amazon  Mechanical  Turk 

Amazon  Mechanical  Turk  is  a  platfonn  where  organizations  find 
employees  for  their  projects.  Amazon  Web  Services  provide  this  platform  to  match  the 
job  requesters  with  the  potential  workers  who  can  be  anywhere  around  the  world.  Job 
requesters  post  the  jobs  to  be  done  on  the  Amazon  Mechanical  Turk  web  page  and  let  the 
workers  choose  one  or  more  to  complete  for  a  monetary  payment  (Bell,  2010). 
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b.  SETI@home 

Another  example  of  Internet  supported  crowdsourcing,  SETI@home  was 
founded  in  1999  and  aims  to  use  the  computing  power  of  the  computers  in  a  crowd  to 
find  any  proof  of  extraterrestrial  life.  Scientists  managing  SETI@home  regard  the  project 
supported  by  the  crowd  more  important  than  their  supercomputers  because  of  the 
computing  power  within  the  crowd  (Howe,  2009). 

C.  VIRTUALIZATION 

Obviously  crowdsourcing  and  virtualization  are  different  academic  disciplines, 
and  it  can  be  a  little  puzzling  for  the  reader  to  jump  directly  from  crowdsourcing  to 
virtualization.  However  because  of  this  thesis’  interdisciplinary  nature  these  two  areas  of 
study  need  to  be  explicitly  stated  here. 

Virtualization  is  the  abstraction  of  computing  resources  such  as  processing  power, 
storage  and  network  bandwidth.  It  helps  simulate  software  or  hardware  and  creates  a 
simulated  environment,  which  is  known  as  virtual  machine  (Scarfone,  Souppaya  and 
Hoffman,  2011).  Virtualized  environments  can  have  one  or  more  of  these  goals: 

•  To  allow  any  device  connected  to  a  network  to  access  any  network- 
enabled  application,  even  if  the  device  and  the  application  were  not 
designed  to  work  compatibly. 

•  To  isolate  two  or  more  applications  to  provide  security  or  to  maintain 
network  resources. 

•  To  isolate  an  application  from  the  operating  system  to  work  with  any  other 
version  of  the  operating  system. 

•  To  increase  the  number  of  users  an  application  can  be  used  for  support  by 
running  the  application  on  different  instances  of  the  operating  system. 

•  To  optimize  the  usage  of  a  system  by  decreasing  the  time  system  resources 
remain  idle. 

•  To  increase  system  availability  via  redundancy  by  guiding  the  user  to  a 
running  system  if  the  previous  system  fails  (Kusnetzky,  2011). 

After  a  brief  introduction  to  virtualization  and  its  use  for  data  centers,  an  overview 
of  the  types  of  virtualization  to  be  used  throughout  the  CSFV  project  will  be  provided  in 
this  section. 
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1.  Virtual  Machine  Monitors  (VMM) 

VMM  is  a  piece  of  software  that  gives  the  abstraction  between  machine  hardware 
and  the  virtual  machine.  VMM  records  every  activity  happening  within  the  limits  of  the 
virtual  machine.  It  provides  resources  when  necessary,  and  it  can  also  forbid  the  usage  of 
resources. 

2.  VMM  Types 

To  virtualize  an  operating  system,  all  instructions  should  be  executed  by 
hardware,  software  or  a  combination  of  both.  These  combinations  have  formed  different 
VMM  models.  The  models  presented  in  this  thesis  will  be  Type  I  and  Type  II  VMM 
models. 


a.  Type  I  VMM 

This  type  runs  directly  on  the  machine  hardware;  that  is  why  this  type  of 
VMM  is  called  “bare  metal.”  A  Type  I  VMM  would  most  likely  be  an  operating  system 
or  kernel  that  can  support  virtual  machines  (Figure  1).  It  would  perform  scheduling  and 
resource  allocation  for  each  virtual  machine  on  the  system.  Processors  should  be  in 
compliance  with  every  virtualization  requirement  that  is  needed  by  Type  I.  This 
compliance  should  provide  the  necessary  protection  for  the  real  system  from  virtual 
machine  borne  intrusions  (DoD  ESX  Server  Guide,  2008). 
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Type  1  Hypervisor 
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Hardware 


Hypervisor 


Host  OS 


Hardware 


Figure  1.  Type  I  and  type  II  VMM  (From  Thomas,  2013) 


b.  Type  II  VMM 

This  type  of  VMM  runs  on  a  host  operating  system  and  is  limited  to  the 
operating  system  resources,  such  as  memory  management,  processor  scheduling,  resource 
allocation  and  hardware  drivers  (Figure  1).  Because  of  these  dependencies  any  operating 
system-related  security  issue  might  affect  the  stability  of  the  Type  II  VMM  (DoD  ESX 
Server  Guide,  2008). 

3.  Security  Considerations  in  Virtualization 

The  overall  security  of  a  virtualization  solution  is  dependent  on  the  security  level 
of  each  of  the  components.  These  components  could  be  the  hypervisor,  host  computer, 
host  operating  system  (OS),  guest  OSs,  applications  on  the  system  and  storage. 
Virtualization  users  should  be  sure  about  the  security  levels  of  these  elements  by  taking 
appropriate  measures  such  as  controlling  access  to  administrator  privileges,  having  up-to- 
date  software,  performing  monitoring  and  analysis  of  logs,  using  anti-malware  software, 
using  host-based  firewalls  and  any  other  mechanism  to  prevent  possible  attacks. 

Having  these  security  measures  for  virtualization  may  not  suffice  to  secure  a 
system,  however,  because  the  virtualization  needs  of  organizations  change  in  every 
situation,  and  each  situation  requires  different  security  approaches.  Here,  we  will  dig 
deeper  into  these  security  approaches  to  clarify  this  concept  and  explain  more  about 
hypervisor  security. 
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a.  Hypervisor  Security 

The  hypervisor  known  as  Virtual  Machine  Monitor  needs  to  be  secured 
using  methods  similar  to  those  used  to  protect  other  software.  The  overall  security  of  the 
virtualized  system  is  directly  linked  to  the  virtualized  management  system.  Such  systems 
should  be  under  absolute  control  of  the  administrators.  For  example  when  the 
administrator  needs  to  connect  to  the  virtualized  system,  remote  access  to  administration 
interfaces  should  be  restricted  by  a  firewall.  If  the  communication  is  carried  by  an 
untrusted  network,  data  should  be  under  encryption  using  Federal  Infonnation  Processing 
Standard  (FIPS)  approved  methods  (Scarfone,  Souppaya  and  Hoffman,  2011). 

Access  should  be  limited  to  the  hypervisor,  especially  if  it  is  a  bare-metal 
type  hypervisor.  Although  most  of  the  bare-metal  hypervisor  access  methods  are  based 
on  user  name  and  password,  some  of  them  still  offer  additional  methods  that  grant  access 
to  the  hypervisor  management  interface. 

Unlike  bare-metal  hypervisors,  hosted  virtualization  environments  do  not 
generally  have  access  controls.  Because  of  this  lack  of  security  measures,  anyone  who 
can  install  an  application  on  the  OS  can  manipulate  the  hypervisor.  This  vulnerability 
necessitates  the  policies  for  organizations  specifying  the  privilege  level  of  accessing  the 
hypervisor.  The  following  guiding  rules  can  help  implement  the  right  policy  for 
hypervisors. 

•  Install  all  updates  for  the  hypervisor  as  soon  as  they  are  released. 

•  Protect  network  communications  via  authentication  and  encryption 
using  FIPS  140-2  cryptographic  modules. 

•  Synchronize  the  virtualized  environment  to  a  trusted  time  server. 

•  Remove  all  unused  hardware  connected  to  a  host  system. 

•  Do  not  use  hypervisor  file-sharing  systems  if  they  are  not  needed. 
The  file-sharing  systems  are  considered  possible  attack  vectors 
(Scarfone,  Souppaya  and  Hoffman,  2011). 

Additionally,  hosted  virtualization  means  that  more  threats  will  be  around 
the  system  because  the  hosting  OS  will  possibly  have  some  vulnerabilities  in  addition  to 
hypervisor  security  concerns.  Unnecessary  applications  on  the  host  OS  should  be 
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removed  because  the  security  of  each  guest  OS  will  be  affected  by  the  host  OS  security 
(Scarfone,  Souppaya  and  Hoffman,  2011). 

So  far  the  biggest  concern  of  security  personnel  is  hiding  hypervisors  from 
the  eyes  of  attackers.  However,  hypervisors  have  certain  characteristics  that  make 
attackers  aware  of  their  existence.  The  hypervisor’s  interactions  with  file  systems, 
registry  and  related  virtual  drives  all  give  some  information  to  potential  attackers.  To 
prevent  such  attacks  against  a  hypervisor  using  virtualized  systems,  organizations  should 
take  into  consideration  the  risks  and  vulnerabilities  (Scarfone,  Souppaya  and  Hoffman, 
2011). 

D.  CLOUD  COMPUTING 

According  to  the  National  Institute  of  Standards  and  Technology  (NIST) 
Definition  of  Cloud  Computing  (Mell  and  Grance,  2009),  cloud  computing  is  a  robust  and 
dependable  pool  of  network  resources,  which  includes  computing,  storage,  applications 
and  databases.  One  of  the  most  important  characteristics  of  this  pool  is  its  rapidly 
releasable  and  on-demand  nature.  This  system  would  require  the  least  management  effort 
and  less  service  provider  interaction  (Mell  and  Grace,  2009).  A  graphic  representation  of 
the  NIST  cloud  computing  model  is  shown  in  Figure  2. 


Figure  2.  NIST  visual  model  of  cloud  computing  (From  Damiani,  2011) 
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1.  Characteristics  of  Cloud  Computing 

According  to  the  NIST  Definition  of  Cloud  Computing,  characteristics  of  this 
computing  include  on-demand  self-service,  broad  network  access,  resource  pooling,  rapid 
elasticity  and  measured  service.  These  characteristics  make  cloud  computing  more 
beneficial  in  terms  of  efficiency  and  innovation  in  comparison  to  the  current  computing 
environment  as  shown  in  Table  1. 
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Cloud  Benefits 

Current  Environment 

•  Improved  asset  utilization 
(server  utilization  >  60-  70%) 

•  Aggregated  demand  and 
accelerated  system  consolidation 
(e.g.,  Federal  Data  Center 
Consolidation  initiative) 

•  Improved  productivity  in 
application  development, 
application  management, 
network,  and  end-user  devices 

•  Low  asset  utilization  (server 
utilization  <  30%  typical) 

•  Fragmented  demand  and 
duplicative  systems 

•  Difficult  to  manage  systems 

Cloud  Benefits 

Current  Environment 

•  Shift  focus  from  asset 
ownership  to  service 
management 

•  Tap  into  private  sector 
innovation 

•  Encourage  entrepreneurial 
culture 

•  Improve  link  to  emerging 
technologies  (e.g.,  devices) 

•  Burdened  by  asset 
management 

•  De-coupled  from  private  sector 
innovation  engines 

•  Risk-averse  culture 

Table  1.  Cloud  benefits:  efficiency  and  innovation  (From  Takai,  2012) 


Several  cloud  computing  benefits  are  detailed  in  the  following  paragraphs. 

On-demand  self-service:  The  user  can  alter  unilaterally  the  system  capabilities 
such  as  computing,  server  and  storage  settings,  if  needed,  and  there  is  no  need  for 
interaction  with  a  Cloud  Service  Provider  (CSP). 

Broad  Network  Access:  Cloud  capabilities  are  available  for  a  wide  variety  of 
thick  and  thin  clients  through  standard  access  methods.  Those  clients  could  be  mobile 
phones,  laptops,  netbooks,  tablet  computers  or  personal  digital  assistants  (PDAs)  (Smoot 
and  Tan,  2012). 

Resource  pooling:  End-user  needs  are  the  main  factor  that  dynamically  assigns 
and  reassigns  the  computing  sources  of  the  CSP.  Those  resources  could  include  storage, 
processing  power,  memory,  network  bandwidth  and  virtual  machines.  The  CSP  has 
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relative  freedom  in  notifying  the  end-user  of  the  actual  physical  locations  of  provided 
resources.  End-users  are  thought  to  be  able  to  access  these  resources  through  an  intranet 
if  they  are  internal  users  and  through  the  Internet  if  they  are  outsiders  (Smoot  and  Tan, 
2012). 

Rapid  Elasticity:  The  CSP  can  quickly  change  the  system  capabilities  to  both 
scale  in  and  out  according  to  the  user  needs.  End-users  mostly  think  that  system 
capabilities  to  provision  are  unlimited  and  usable  (Mell  and  Grance,  2009). 

Measured  Service:  Cloud  computing  capabilities  are  under  the  control  and 
surveillance  of  the  CSP,  with  the  help  of  a  measuring  system  that  often  operates  on  a  pay- 
per-use  basis.  This  system  provides  transparency  of  used  service  (storage,  computing, 
bandwidth)  for  both  the  cloud  provider  and  the  end-user  (Mell  and  Grance,  2009). 

2.  Cloud  Computing  Deployment  Models 

There  are  four  deployment  models  of  cloud  computing: 

Public  Cloud:  This  type  of  cloud  is  available  to  almost  anyone  in  the  crowd  who 
can  access  the  Internet.  With  the  development  of  cloud  technologies,  service  providers 
operating  in  this  area  are  increased.  Some  widely  known  examples  include  Amazon’s 
Elastic  Compute  Cloud  (EC2),  Rackspace’s  Cloud  Offerings,  and  IBM’s  BlueCloud 
(Winkler,  2011).  While  these  providers  primarily  offer  Infrastructure  service,  there  are 
others  that  give  Application  layer  service,  such  as  Google’s  AppEngine  and  Windows’ 
Azure  Services  platform. 

From  a  security  perspective  public  clouds  can  be  considered  both  secure  and 
unsecure.  They  are  considered  secure  because  public  clouds  are  mainly  operated  by  large 
scale  CSPs.  Therefore  they  should  have  enough  security  measures,  including  access 
control,  data  ownership  and  encryption  (Winkler,  2011).  On  the  other  hand,  end-users 
leave  their  data  in  the  hands  of  the  provider  not  knowing  whether  it  is  secure  or  not.  CSPs 
have  no  obligation  to  their  customers  regarding  the  location  of  the  stored  data.  If  data  is 
stored  offshore  in  another  country,  the  data  is  expected  to  be  subject  to  the  laws  of  the 
hosting  country  (Winkler,  2011). 
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Private  Clouds:  Private  clouds  are  hosted  internally  and  basically  serve  only  one 
organization.  Unlike  data  on  public  clouds,  data  on  private  clouds  are  not  mixed  with 
external  users’  data.  However,  organizations  may  want  to  provide  data  isolation  to  satisfy 
the  needs  of  the  organization’s  own  subunits  (Winkler,  2011).  Private  clouds  can  be 
owned,  maintained  and  operated  by  either  the  organization  itself,  a  third  party  or  a 
combination  of  both  (Mell  and  Grance,  2009). 

From  a  security  perspective  private  clouds  have  more  constraints  than  public 
clouds  because  small  scale  organizations  may  not  address  the  computation  needs  as  do 
large  scale  CSPs  operating  public  clouds.  It  would  also  be  incorrect  to  assume  that 
private  clouds  are  more  secure  than  public  ones  (Winkler,  2011).  Considering  that  private 
clouds  use  virtualization  to  save  more  on  computing  resources,  private  cloud  providers 
should  obtain  measures,  such  as  hypervisor  and  virtual  machine  security,  to  secure  the 
virtualization  environment  (Winkler,  2011).  The  point  of  operating  private  clouds  is  that 
we  can  address  the  security  issues  by  ourselves  and  are  free  to  use  any  further  measures 
that  we  deem  appropriate.  We  have  the  chance  to  implement  the  security  architecture 
according  to  organizational  needs.  In  this  sense  a  private  DoD  cloud  can  employ  stricter 
security  measures  than  a  private  cloud  that  is  owned  by  a  business  corporation. 

Community  Clouds:  The  cloud  infrastructure  is  created  for  the  use  of  multiple 
independent  organizations  that  have  the  same  concerns  (that  is,  security,  mission, 
regulation,  policy  or  compliance).  The  system  may  be  owned  and  maintained  by  each  of 
the  organizations,  a  third  party  or  a  combination  of  them  (Mell  and  Grance,  2011).  This 
model  presents  a  valuable  opportunity  for  the  organizational  entities  that  have  similar 
legal  and  compliance  restrictions.  Different  levels  of  community  clouds  are  being 
considered  both  by  the  governments  of  the  United  States  and  the  European  Union. 
Governments  will  benefit  because  inter-government  business  transactions  are  considered 
to  be  processes  in  a  possessed  environment  and  will  cause  no  additional  costs  as  does  the 
Internet  (Winkler,  2011). 

Hybrid  Clouds:  This  cloud  infrastructure  can  be  a  combination  of  two  or  more 
different  cloud  types,  as  shown  in  Figure  3.  Here  separate  and  different  clouds  remain  as 

a  unique  entity,  and  each  of  them  is  linked  to  others  via  a  technology  that  enables  secure 
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data  transmission  (Mell  and  Grance,  2011).  Hybrid  clouds  are  generally  preferred  by 
entities  that  operate  private  clouds.  The  main  reason  for  this  preference  could  be  either 
security  related  or  financial.  An  entity  such  as  the  DoD  can  have  its  confidential  data  in 
the  private  cloud  and  store  unclassified  data  in  the  public  cloud.  Here  hybrid  cloud 
infrastructures  will  allow  the  necessary  data  transfer  of  the  organization  (Winkler,  2011). 


Figure  3.  Hybrid  cloud  (From  Shilovitsky,  2013) 

E.  CLOUD  COMPUTING  SERVICE  MODELS 

Software  as  a  Service  (SaaS):  The  applications  running  on  a  CSP’s 
infrastructure  are  the  services  provided  to  the  consumer.  Those  applications  could  either 
be  accessed  via  thin  clients,  such  as  a  web  browser,  or  via  the  interface  of  software.  The 
consumer  has  no  privilege  to  change  any  settings  of  infrastructure,  servers,  operating 
systems,  or  storage  except  for  some  limited  application  configurations  (Mell  and  Grance, 
2011).  Moreover,  consumers  may  not  want  to  change  those  settings.  Google’s  GMAIL  or 
Yahoo  mail  services  can  be  considered  examples  of  SaaS  (Winkler,  2011). 

Platform  as  a  Service  (PaaS):  The  consumer  is  capable  of  using  his  own 
application  or  an  application  provided  by  the  CSP,  as  well  as  the  libraries,  services  and 
tools  (Mell  and  Grance,  2011).  The  consumer  has  control  only  over  the  applications  he 
uses.  He  does  not  and  cannot  control  the  infrastructure,  operating  systems  or  servers 
provided  by  the  CSP.  In  this  sense,  the  PaaS  is  similar  to  the  SaaS  model.  However,  the 
PaaS  model  is  different  because  the  consumer  owns  the  application.  Google  App  Engine 
could  be  an  example  of  the  PaaS  model  (Winkler,  2011). 
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Infrastructure  as  a  Service  (IaaS):  This  service  model  has  the  most  flexible 
components  provided  to  the  consumer.  In  this  model  consumers  can  change  applications, 
storage  components,  operating  systems,  databases  and  even  some  limited  networking 
entities  such  as  host  firewalls  (Mell  and  Grance,  2011).  Some  CSPs,  including  Amazon, 
go  further  providing  services  that  the  consumer  can  access  through  a  platform  of  routers, 
switches  and  data  centers  (Winkler,  2011).  This  model  is  compared  to  other  cloud 
computing  models  in  Figure  4. 
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Figure  4.  Comparison  of  service  models  (From  Lau,  2011) 


From  a  security  perspective  the  IaaS  model  is  preferable  for  an  organization  like 
the  DoD.  No  matter  which  cloud  type  the  DoD  utilizes,  the  necessary  solution  seems  to 
be  the  IaaS  model. 

F.  ENTERPRISE  NETWORK  SECURITY 
1.  Network  Security  Concepts 

The  term  “network  security”  is  derived  from  “computer  security.”  According  to 
NIST,  computer  security  comprises  the  necessary  protection  mechanisms  to  provide 
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confidentiality,  integrity  and  availability  of  data  being  processed  (Stallings  and  Brown, 
2008).  These  three  terms  are  widely  known  as  the  CIA  Triad,  and  they  lay  out  the 
essential  principles  concerning  data  and  information  security.  The  CIA  Triad,  shown  in 
Figure  6,  refers  to  the  confidentiality,  integrity  and  availability  of  data.  Confidentiality 
avoids  the  unnecessary  disclosure  of  infonnation  to  unauthorized  parties.  Integrity 
protects  information  so  that  it  cannot  be  changed  in  an  unauthorized  manner.  Availability 
makes  sure  that  information  is  always  available  for  authorized  users  and  keeps  the  system 
in  service  (Stallings  and  Brown,  2008). 


Figure  5.  The  security  triad  (From  Chou,  2012) 

2.  Security  Vulnerabilities,  Threats  and  Countermeasures 

As  former  Secretary  of  Defense  Leon  Panetta  noted  repeatedly,  the  next  Pearl 
Harbor  is  expected  to  happen  soon,  but  this  time  from  the  cyber  domain  (Panetta,  2012). 
Current  Secretary  of  Defense  Chuck  Hagel  also  drew  attention  to  the  importance  of  cyber 
security  from  a  global  perspective  (Hagel,  May  2013).  Indeed,  providing  cyber  security  is 
firstly  a  macro  level  necessity.  According  to  the  Advanced  Cyber  Threat  Report  cyber 
threats  share  almost  the  same  importance  level  as  nuclear  armament  issues  (Defense 
Science  Board,  2013).  In  this  thesis  study  we  will  use  an  enterprise  level  approach  and 
analyze  vulnerabilities,  possible  threats  and  necessary  cyber  countermeasures  to  mitigate 
the  security  risks  related  to  cloud  computing. 
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a. 


Security  Vulnerabilities 


In  the  security  context,  when  we  refer  to  security  vulnerabilities  we  mean 
the  vulnerabilities  of  system  resources  such  as  computing  power  and  storage.  This 
resource  could  be  damaged  or  changed  in  such  a  way  that  it  differs  from  what  it  is 
supposed  to  be.  The  resource  may  be  leaky,  giving  infonnation  to  unauthorized  parties. 
Also  the  resource  could  be  unavailable  or  very  slow,  and  it  may  not  serve  system  users  as 
expected  (Stallings  and  Brown,  2008). 

Unnecessary  open  ports:  An  open  port  is  used  for  communication 
between  computer  systems  on  a  network.  A  designated  software  works  on  a  single  port 
(e.g.,  Mail  service  works  on  port  25  on  most  computers).  When  a  port  is  open  it 
continuously  listens  for  possible  communications  intended  for  it.  If  the  service  running 
on  the  port  is  unnecessary  that  port  should  be  closed  to  decrease  the  vulnerability  level. 

Unpatched  systems:  System  security  vulnerabilities  exist  in  almost  all 
computer  systems  and  software.  They  are  supposed  to  be  patched  by  the  vendors  to  avoid 
vulnerabilities  because  hackers/attackers  look  for  holes  in  such  systems  to  exploit  them 
via  malicious  codes  (Gregory,  2010).  Most  software  vendors  react  quickly  to  distribute 
patches  to  fix  the  security  holes,  and  system  users  are  expected  to  apply  those  patches. 
When  necessary  patches  are  not  installed  on  the  system,  it  becomes  vulnerable  to  possible 
threats. 


b.  Security  Threats 

A  security  threat  is  the  possibility  of  an  adverse  condition  affecting 
computer  systems.  This  threat  could  be  realized  from  outside  the  enterprise  or  even  from 
within  an  enterprise  by  a  disgruntled  employee  (Gregory,  2010). 

Denial  of  Service  (DoS):  The  DoS  prevents  or  limits  the  intended  use  of 
communication  infrastructures.  An  attacker  can  scale  his  attack  to  a  limited  level  such  as 
the  recording  of  security  audits.  Sometimes  he  aims  to  take  the  whole  network  down  by 
disabling  it  or  overloading  the  network  with  random  messages  to  downgrade  performance 
levels  (Stallings  and  Brown,  2008). 
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A  developed  form  of  DoS  attack  is  the  Distributed  Denial  of  Service 
(DDoS)  attack,  which  targets  network  resources  by  overwhelming  traffic.  DDoS  attacks 
could  originate  from  thousands,  or  even  hundreds  of  thousands  of  systems.  Highly 
complicated  DDoS  attacks  use  a  botnet  (see  Figure  7),  which  is  a  collection  of  zombie 
computers,  controlled  by  botnet  operators  (Gregory,  2010). 


Fgw*  4  4  DDoS  Artjci 


Figure  6.  Distributed  Denial  of  Service  attack  (From  Masikos  et.al.,  2004) 

Sequence  Number:  Sequence  number  attacks  attempt  to  hijack  or  fail  a 
TCP  session  between  two  parties  by  guessing  the  sequence  number  of  any  of  the  TCP 
packets  and  achieving  a  correct  timing.  The  attacker  then  sends  false  packets  to  either  one 
of  the  parties  pretending  to  be  a  valid  sender. 

Smurf:  A  smurf  attack  includes  a  large  number  of  fake  Internet  Contol 
Message  Protocol  (ICMP)  echo  requests.  The  ICMP  packets  are  sent  to  the  broadcasting 
address  of  the  target  network,  causing  all  the  devices  to  respond  with  ICMP  packets  as 
well.  The  attacker  changes  the  “from”  part  of  the  packets  to  the  target  system’s  IP 
address.  When  all  of  the  devices  send  replies  to  the  echo  request  the  target  system  gets 
overloaded  (Gregory,  2010). 
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Spam:  Spam  attacks  comprise  a  high  volume  of  emails  which  mostly  have 
commercial  origins.  Spam  on  the  Internet  is  estimated  to  account  for  90%  of  all  email 
communication.  Spam  aims  to  degrade  the  performance  of  network  devices  by  evading 
frequently  used  spam  fdters  (Gregory,  2010). 

Phishing:  Phishing  is  a  type  of  spam,  and  it  is  performed  by  sending  mails 
while  masquerading  as  official  parties  such  as  banks,  hospitals  or  government  agencies. 
After  defrauding  the  mail  recipients,  the  attacker  gathers  some  important  personal 
infonnation  like  credit  card  or  social  security  numbers  (Gregory,  2010). 

SQL  (Structured  Query  Language)  Injection:  SQL  injection  attacks  are 
one  of  the  most  significant  threats  to  websites  and  databases.  This  type  of  attack  mainly 
aims  to  introduce  some  malicious  input,  such  as  SQL  codes,  to  a  website  and  then  gather 
confidential  or  other  sensitive  information  from  the  linked  database.  The  basic  cause  of 
SQL  injection  attacks  is  insufficient  input  validation  measures  (Halfond  and  Orso,  2005). 
This  type  of  attack  succeeds  when  input  from  a  website  visitor  is  accepted  as  a  database 
SQL  query  without  being  validated.  The  attacker  then  becomes  able  to  perform  his  SQL 
query  embedded  in  the  input  for  the  website.  In  this  way  the  intruder  can  gather,  modify 
and  delete  data  in  the  database.  Clearly  it  is  a  threat  for  all  three  domains  of  information 
security  (i.e.,  confidentiality,  integrity  and  availability).  In  our  proposed  CSFV  project  to 
be  run  on  DREN,  the  CSFV  website  could  be  vulnerable  to  this  kind  of  attack  because  of 
the  nature  of  its  web-based  applications. 

Cross  Site  Scripting  (XSS):  An  XSS  threat  resembles  the  previous  threat 
of  SQL  injection  in  the  way  that  a  website  lacks  security  measures  to  check  the  input 
coming  from  users.  XSS  targets  the  website  as  content  defacement  or  DDoS  attacks, 
whereas  SQL  injection  aims  to  manipulate  the  database  behind  the  website  (Ernst,  2009). 
According  to  past  research  XSS  attacks  moved  to  the  top  of  the  cyber  threat  assessment 
in  documents  such  as  “SANS  Top  25  Most  Dangerous  Software  Errors”  and  Open  Web 
Application  Security  Project  (OWASP)  lists,  passing  the  famous  buffer  overflow  attacks. 
Basically  XSS  attacks  use  special  characters  when  giving  input  to  Hyper  Text  Mark-up 
Language  (HTML)  documents  such  as  adding  <script>  to  inputs  to  invoke  the 

JavaScripts  interpreter.  When  the  browser  does  not  perform  input  validation,  the  attacker 
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becomes  successful  and  finds  ways  to  further  exploit  the  website  such  as  account 
hijacking,  cookie  poisoning  and  even  Denial  of  Service  (Shar  and  Tan,  2012). 

c.  Security  Countermeasures 

Encryption  composes  the  essential  part  of  network  security  and  security 
countermeasures.  It  includes  two  main  pieces  of  information  security:  Symmetric  Key 
Encryption  and  Asymmetric  Key  Encryption.  In  short,  symmetric  encryption  means 
having  a  single  key  for  each  cryptographic  algorithm,  whereas  asymmetric  encryption 
uses  two  different  keys,  one  of  which  would  be  known  by  public  (Diffie  and  Helman, 
1976).  The  other  key  is  supposed  to  be  kept  secret  by  its  owner  and  would  be  used  to 
decrypt  the  messages  that  were  previously  encrypted  by  the  other  public  key.  Key 
distribution  in  symmetric  encryption  is  known  to  be  easy  because  there  is  only  a  single 
key  to  be  controlled  by  two  users.  Although  key  distribution  is  more  difficult  in 
asymmetric  ciphers,  it  is  more  secure.  The  common  feature  of  both  symmetric  and 
asymmetric  ciphers  is  that  the  algorithm  would  be  known  by  everyone,  but  the  key  is 
supposed  to  be  known  just  by  owner  as  explained  in  Kerckhoffs’s  principle  (Kerckhoffs, 
1883). 

The  network  security  concept  also  includes  practical  applications  such  as 
IPsec  technology,  firewalls  and  authentication  (Tanenbaum,  2003).  Some  of  these 
applications  will  be  used  as  system  security  measures  in  the  experimentation  sections  of 
this  thesis. 

IPsec  (IP  Security):  Being  originally  a  communications  security  measure, 
IPsec  was  created  to  fill  the  security  gap  throughout  Internet.  The  argument  at  the  first 
point  was  to  provide  data  security  either  end-to-end  fashion  or  just  on  the  network  with 
unaware  users.  After  long  discussions  among  security  experts  a  security  model  emerged, 
and  it  was  designed  to  provide  network  level  security  (Tanenbaum,  2003).  IPsec  has  two 
modes  of  operation,  which  are  transport  mode  and  tunnel  mode.  The  advantage  of  tunnel 
mode  is  that  it  adds  another  IP  layer  onto  the  packet,  making  data  transfer  easier  and 
concealing  flow  of  data  in  a  better  way. 
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Firewalls:  The  need  for  firewalls  emerged  after  fast  improvement  of 
networks  by  means  of  connectivity  and  speed.  Especially  when  networks  overcame  the 
size  of  premises  and  started  forming  Wide  Area  Networks  (WAN)  with  the  need  for 
better  connectivity,  network  input-output  controls  became  more  important.  Then  firewalls 
started  to  be  used  (Stallings,  2008).  Essentially  a  firewall  is  composed  of  two  routers 
working  as  packet  filters  and  an  application  gateway.  The  point  here  is  to  force  all  of  the 
traffic — incoming  and  outgoing — to  use  the  route  through  the  firewall.  This  way  the 
firewall  will  allow  or  prohibit  certain  IP  packets  depending  on  whether  the  packets  are 
authorized  or  not.  This  allow-or-prohibit  decision  is  made  by  using  IP  numbers  and  port 
numbers.  For  instance,  firewalls  should  prohibit  data  traffic  coming  to  port  23,  which  is  a 
telnet  port  (Tanenbaum,  2003). 

Intrusion  Prevention  Systems  (IPS):  An  IPS  is  a  network-based 
Intrusion  Detection  System  (IDS)  with  an  additional  capability  of  dropping  packets  and 
blocking  traffic  as  well  as  detecting  malicious  traffic  and  sounding  alarms.  IPSs  can 
either  be  in  a  form  of  host  based  or  network  based  (Stallings,  2008). 

A  host-based  IPS  can  check  packets  depending  on  their  signatures  or  by 
using  heuristics.  Signature  checking  is  controlling  the  payloads  coming  with  the  packets. 
The  drop  or  allow  decision  is  made  depending  on  the  presence  of  malicious  content. 
When  heuristics  are  used,  the  IPS  looks  for  anomalies  and  misbehaviors  of  packets  which 
can  be  either  a  modification  of  system  resources,  privilege-escalation  exploits,  buffer- 
overflow  exploits  or  access  to  email  contact  lists  (Stallings,  2008). 

A  network-based  IPS  is  an  inline  device  that  has  the  capability  of 
inspecting  Transmission  Control  Protocol  (TCP)  packets  by  tearing  them  down.  It  applies 
this  inspection  on  every  incoming  data  flow,  and  when  a  malicious  behavior  is  seen,  all 
the  future  data  packets  pertaining  to  that  data  flow  are  dropped.  Some  of  the  techniques 
used  by  network-based  IPS  systems  to  find  malicious  packets  are  pattern  matching, 
stateful  matching  and  protocol  anomaly  (Stallings,  2008).  An  example  of  network-based 
IPS  is  SNORT,  which  is  an  open-source,  network-based,  intrusion  prevention  system.  It 
can  employ  signature -based,  protocol-based  and  anomaly-based  inspection. 
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III.  NETWORK  DESIGN 


A.  INTRODUCTION 

In  this  chapter  a  secure  CSFV  network  design  will  be  discussed,  key  network 
design  questions  will  be  asked,  potential  security  vulnerabilities  and  threats  specifically 
relevant  to  CSFV  networks  will  be  presented  and  the  necessary  network  components  for 
optimal  system  security  will  be  explained. 

Before  examining  the  network  design,  it  is  important  to  understand  the  following 
facts  about  the  surrounding  environment: 

•  The  games  and  the  database  infrastructure  are  not  yet  released  at  the  time 
this  chapter  is  being  written,  so  the  design  principles  in  this  document  will 
refer  to  presentations,  drafts  or  other  kinds  of  documents  related  to  CSFV 
studies  of  CSFV  vendors  or  DARPA. 

•  The  network  infrastructure  will  be  focused  on  security  design,  which  does 
not  mean  that  performance  factors  of  the  network  are  totally  ignored; 
rather  they  will  be  discussed  optimally  with  a  security  emphasis. 

•  This  system  will  first  be  deployed  on  the  NPS  Intranet  and  then  transferred 
to  DREN.  Design  decisions  will  be  made  according  to  Defense 
Information  Systems  Agency  (DISA)  Security  Technical  Implementation 
Guides  (STIG). 

•  The  necessary  security  measures  such  as  the  location  of  firewalls,  usage  of 
IPS  or  IDS,  network  segmentation  for  better  security  and  specific  services 
(reverse  proxy)  will  be  discussed  in  this  chapter.  More  detailed  design 
parameters  such  as  operating  systems,  firewall-IDS  rules,  and 
virtualization  technologies  to  be  used  in  the  CSFV  network  will  be 
presented  in  Chapter  4. 

B.  NETWORK  DESIGN  CONSIDERATIONS  AND  GUIDELINES 

Several  network  design  publications  were  used  as  guidelines  while  creating  the 
CSFV  network.  The  first  of  those  publications  is  written  by  the  National  Institute  of 
Standards  and  Technology:  NIST  Special  Publication  (SP)  800-44,  Guidelines  on 
Securing  Public  Web  Servers,  explains  how  to  operate  public-facing  web  servers  for 
organizations  such  as  the  DoD  and  the  private  sector.  It  presents  general 
recommendations  about  web  servers,  including  operating  system  (OS)  choice, 
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virtualization  of  OSs  and  communication  security  between  web  servers  and  database 
servers. 

CSFV  networks  would  run  on  DREN-owned  infrastructure,  so  the  initial  design 
principles  should  be  also  in  compliance  with  the  publications,  which  set  networking  rules 
for  DREN.  Network  Infrastructure  STIG  (2007)  and  Web  Server  STIG  (2006)  are  two 
publications  that  we  used  to  build  our  network.  According  to  these  documents  an 
optimum  level  of  network  security  should  be  provided  by  the  following  security 
measures: 

•  DoD  networks  should  be  layered  according  to  the  information  security 
levels  that  those  layers  contain. 

•  The  security  in-depth  principle  should  be  used  in  locating  the  network 
components. 

•  DoD  system  administrators  should  install,  maintain  and  operate  IDS  inside 
their  networks  with  the  capability  of  logging. 

•  Firewalls  and  web  proxies  should  be  deployed  for  perimeter  security. 

•  Web  servers  and  database  servers  should  reside  on  separate  devices. 

•  Web  servers  should  use  Secure  Sockets  Layer  (SSL)  and  Transport  Layer 
Security  (TLS). 

C.  NETWORK  TOPOLOGY 

We  had  three  main  goals  before  starting  to  design  this  network:  to  create  a 
topology  that  shows  the  physical  and  logical  elements  of  the  network;  to  secure  the 
network  components  against  the  most  common  threats  of  the  day  and  from  ones  possible 
in  the  near  future;  and  to  prevent  those  security  measures  from  degrading  the  throughput 
of  the  network. 

There  were  a  couple  of  issues  in  mind  in  the  design  process: 

•  securing  the  network  from  both  Internet  and  possible  insider  attacks, 

•  using  a  multi-layered  security  approach  to  secure  sensitive  and  classified 
infonnation  such  as  the  database  server, 

•  having  additional  systems  for  logging,  encryption  and  intrusion  detection 
(SANS  Institute,  2003). 
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Figure  7.  CSFV  Network  topology. 

To  examine  the  architecture  in  our  network,  we  focused  on  the  following  seven 
questions: 

•  Why  do  we  use  virtualization  technology  for  game  servers  and  database 
servers? 

•  Why  are  game  servers  and  database  servers  designed  to  reside  on  separate 
physical  servers  rather  than  being  virtualized  on  the  same  machine? 

•  Why  do  we  use  IDS,  not  IPS? 

•  Why  do  we  use  two  separate  IDSs? 
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•  What  is  the  design  principle  related  to  using  two  firewalls,  and  what  are 
their  roles? 

•  What  is  our  goal  in  using  a  reverse  proxy? 

•  Is  encryption  necessary  in  CSFV  network  design,  and  how  will  it 
function? 

D.  SEGMENTED  DESIGN 

In  this  section  detailed  answers  will  be  given  to  the  preceding  questions  by 
partitioning  the  network  (Figure  7)  and  explaining  it  part  by  part. 

1.  Border  Router  and  Firewall 

There  will  be  a  router  and  a  firewall  at  the  point  where  our  network  connects  to 
the  Naval  Postgraduate  School  (NPS)  website  (nps.edu),  as  shown  in  Figure  7.  The  router 
and  firewall  can  be  either  separate  devices,  or  they  could  be  designed  to  reside  on  the 
same  physical  server  as  a  multi-functional  system.  The  decision  on  this  location  will  be 
given  at  the  implementation  phase. 

When  choosing  the  type  of  firewall,  we  had  a  couple  of  options.  It  could  be  a 
packet  filter  firewall,  which  would  operate  at  Layer  3,  a  stateful  inspection  firewall 
operating  at  Layer  4  or  a  deep  packet  inspection  firewall,  which  additionally  inspects 
application  level  loads.  A  packet  filter  firewall  would  be  a  poor  choice  because  this  type 
of  firewall  accepts  every  packet  without  looking  at  the  destination  port.  The  third  choice, 
a  deep  packet  inspection  firewall,  would  possibly  create  a  choke  point  at  the  entrance  of 
the  network  and  decrease  the  throughput.  A  stateful  inspection  firewall  was  the  optimal 
solution  both  for  the  IP  packet  inspection  security  and  for  the  system  performance. 
Choosing  to  use  stateful  inspection  firewalls  is  also  necessary  in  utilizing  the  second 
firewall,  which  comes  behind  the  switch.  The  application  level  packet  inspection  job  of 
the  two  firewalls  would  be  executed  by  the  IDSs.  Again,  this  decision  was  based  on 
system  perfonnance  concerns,  not  to  mention  the  high  cost  of  deep  packet  inspectors  or 
the  technical  difficulty  in  utilizing  them  effectively. 

The  first  firewall  will  be  configured  to  inspect  packets  which  are  coming  to  the 
reverse  proxy  server  that  will  be  in  the  demilitarized  zone  (DMZ),  whereas  the  second 
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firewall  looks  into  the  packets  coming  to  the  database  server.  This  second  firewall  only 
allows  the  packets  coming  from  the  address  of  game  servers  to  database  server.  In  case  of 
a  compromise  of  the  reverse  proxy,  the  attacker  will  not  be  able  to  access  the  database 
server  because  of  this  second  firewall  behind  the  DMZ. 


Figure  8.  Firewall  design. 


2.  IDS 

To  further  protect  the  required  network  additional  elements,  in  this  phase  we  had 
the  option  of  using  IPS,  IDS  or  both.  When  we  consider  that  IPS  would  inspect  a  packet 
and  sometimes  necessarily  drop  it,  we  identified  this  possibility  as  a  drawback  for 
network  throughput  by  generating  false  alarms  (i.e.,  false  positives).  That  is  the  reason 
we  chose  to  use  IDS.  IDS  will  stay  on  the  network  and  watch  the  ongoing  traffic  without 
interfering.  It  will  start  an  alarm  when  malicious  packets  or  abnormal  network  activity  are 
detected.  IDS  will  inspect  the  packets  by  comparing  them  to  attack  signatures  or  pre¬ 
installed  IDS  rules  (DISA,  2007).  The  reason  we  use  two  separate  IDS  devices  is  to 
provide  security  in  depth  throughout  the  network.  While  the  first  IDS  is  inspecting  the 
traffic  in  the  DMZ,  the  second  IDS  will  operate  in  a  more  secure  part  of  the  network  and 
will  look  for  anomalies  or  attack  signatures  targeting  the  database  server. 
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IDS 


Figure  9.  IDS  deployment. 


3.  Game  Servers  and  Database  Server 

Game  servers  in  the  DMZ  will  be  virtualized  on  the  same  physical  server  to 
provide  efficient  resource  utilization.  The  number  of  game  servers  will  initially  be  two, 
and  this  initial  design  will  test  the  systems  in  a  simple  infrastructure  with  as  few  negative 
factors  as  possible.  Furthermore,  the  CSFV  network  would  eventually  be  deployed  on  a 
DoD  cloud  (Dean,  2013),  and  a  virtualized  environment  on  the  NPS  network  will  help  us 
find  and  solve  any  potential  vulnerabilities  related  to  virtualization  before  this  final 
deployment. 

We  plan  to  operate  the  game  servers  in  a  virtualized  environment;  however,  the 
database  server  will  reside  on  another  physical  server.  The  reason  for  this  design  is  to 
have  multiple  security  layers  in  the  network  and  to  prevent  any  attacker  from  gaining 
access  to  our  database  server  after  compromising  a  game  server.  It  is  basically  a  two-fold 
security  measure.  Firstly,  we  avoid  a  virtualization-related  “escape  attack,”  in  which  an 
attacker  easily  jumps  to  another  virtualized  system  after  accessing  one  virtualized 
environment.  Secondly,  our  design  makes  an  attack  more  difficult  by  putting  the  database 
in  the  trusted  layer  of  our  network. 


32 


Figure  10.  Database  server. 

4.  Reverse  Proxy  Server 

A  reverse  proxy  will  be  running  between  the  game  servers  and  their  clients.  It  will 
serve  as  a  proxy  server  operating  in  the  reverse  direction.  The  clients  of  game  servers  will 
not  know  the  IP  address  of  the  game  servers;  rather  they  will  know  the  address  of  the 
reverse  proxy  server  and  communicate  with  it.  Because  reverse  proxies  are  specially 
designed  systems  they  are  more  trusted  and  secure  than  regular  servers. 

Additional  features  of  reverse  proxies  are  caching  and  load  balancing.  Caching 
increases  the  speed  of  the  network  by  keeping  the  most  frequently  used  records-data  and 
retrieving  them  upon  request.  Load  balancing  will  distribute  the  traffic  of  Hyper  Text 
Transfer  Protocol  (HTTP)  and  Hyper  Text  Transfer  Protocol  Secure  (HTTPS)  over  the 
two  game  servers,  which  will  allow  us  to  increase  the  number  of  game  servers  as  the 
number  of  gamers  expands.  Moreover  a  load-balanced  server  will  withstand  the  high 
volume  of  requests  during  a  possible  DoS  attack  by  distributing  the  workload  to  many 
servers. 


Figure  1 1 .  Reverse  proxy  server. 
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E.  ADDITIONAL  SECURITY  MEASURES 

1.  Encryption 

Data  traffic  between  the  reverse  proxy  server  and  its  clients  will  be  encrypted 
using  SSL/TLS.  The  outcome  traffic  will  be  HTTPS  which  is,  in  short,  an  HTTP  session 
encrypted  with  SSL/TLS.  The  only  port  that  will  be  open  is  port  443  (DISA,  2006). 

It  is  also  determined  that  encrypting  only  the  communication  between  server 
clients  and  the  reverse  proxy  server  would  be  enough.  Other  than  that  the  traffic  between 
the  game  servers  and  database  server  will  not  be  encrypted  to  keep  performance  levels 
high. 


2.  Authentication 

Another  fact  about  SSL/TLS  encryption  is  that  it  will  provide  server/client 
authentication  by  exchanging  digital  signatures  between  the  reverse  proxy  server  and  its 
client.  When  a  gamer  wants  to  access  a  game  site  SSL/TLS  authentication  will  occur,  and 
the  browser  of  the  gamer  will  handshake  with  the  server  via  the  server’s  digital  signature. 
This  digital  signature  can  be  provided  in  two  ways:  creating  and  getting  it  verified  from  a 
third  party  Certificate  Authority  (CA)  or  by  creating  and  signing  itself  (Tracy,  2007). 
Here,  the  digital  signature  will  not  be  provided  by  a  third  party,  it  will  be  created  by  the 
server  itself. 

User  authentication  with  passwords  and  user  names  will  be  provided  by  the 
gaming  software. 
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IV.  IMPLEMENTATION 


A.  INTRODUCTION 

In  the  previous  chapter  we  have  mentioned  facts  about  the  network  design  and 
topology  and  explained  the  design  process  including  the  proper  locations  of  network 
elements,  necessary  services  to  be  used  by  those  elements  and  security  concepts  to  be 
applied  to  provide  confidentiality,  integrity  and  availability.  We  have  also  validated  the 
deployment  of  separate  subnets  and  security  components  according  to  the  necessary 
documents  of  DISA-DoD. 

In  this  chapter  we  will  explain  how  we  implemented  our  system  with  a  slight 
difference  from  the  initial  design.  We  will  show  the  details,  such  as  IP  addressing¬ 
subnetting,  server  operating  system  selections,  proper  usage  of  the  necessary  network 
services,  firewall  rules  and  IDS  rules  for  efficient  network  security.  At  the  end  we  will 
perform  a  network  penetration  test  with  popular  attack  tools. 

We  will  not  discuss  the  troubles  we  came  across  while  implementing  the  firewall 
and  IDS  rules  although  there  were  many,  and  we  spent  a  considerable  amount  of  time 
troubleshooting  them.  In  particular,  Redhat  license  expirations,  conflicts  between  firewall 
rules  and  reverse  proxy  encryption  issues  were  some  of  those  troubles  that  we  needed  to 
address. 
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B. 


GENERAL  NETWORK  INFORMATION 


1.  Network  Topology  Implementation 


Figure  12.  Subnets  in  the  CSFY  Network. 


Subnetting  is  necessary  in  the  networks  to  maintain  security.  Our  network 
elements  are  distributed  through  three  subnets  (Figure  12),  which  are  172.20.104.0, 
10.0.0.0  and  192.168.0.0.  While  nps.edu  maintains  a  subnet  of  255.255.0.0  for  the 
172.20.104.0  network,  the  author  used  255.255.255.0  subnet  both  for  10.0.0.0  and 
192.168.0.0  networks.  The  main  idea  behind  having  separate  subnets  is  to  provide 
security  in  depth  and  to  have  a  security-enhanced  network  architecture. 

After  creating  the  initial  design  for  the  CSFV  network  architecture  we  decided  to 
make  some  small  changes  on  the  first  design.  The  first  of  those  changes  is  to  remove  the 
border  router  and  replace  it  with  the  reverse  proxy. (Figure  13)  With  this  change  the 
landing  machine  of  the  network  becomes  the  reverse  proxy,  which  also  runs  a  firewall  on 
itself.  By  moving  the  reverse  proxy  to  a  different  network  than  the  game  servers,  we  aim 
to  avoid  a  possible  attack  scenario  that  can  compromise  the  game  servers  by  estimating 
their  IP  address  range.  Because  those  servers  will  be  on  separate  networks,  the  attacker 
will  not  easily  use  a  network  scanner  (such  as  nmap)  and  get  access  to  the  game  servers. 

The  second  change  to  the  initial  design  is  to  configure  the  second  IDS  as  a  host- 
based  IDS,  rather  than  a  network-based  IDS.  With  this  change  our  goal  is  to  run  the  first 
IDS  to  detect  network-based  attacks  such  as  man-in- the-middle,  packet  sniffing  and 
network  scanning,  whereas  the  second  IDS  is  to  be  run  on  a  server  (database  server)  and 
detect  the  attacks,  such  as  DDoS  and  password  attacks. 
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2.  Implementation  of  Servers 

There  are  a  total  of  four  servers,  two  IDS  machines  and  two  firewalls  in  the  CSFV 
network.  Each  of  them  is  either  virtualized  on  a  physical  server  or  not  virtualized, 
depending  on  its  usage.  For  example,  the  reverse  proxy  server  stays  at  the  entrance  of  the 
network  as  a  border  router  and  forwards  traffic  back  and  forth.  Because  it  also  runs  a 
firewall  on  it,  we  gave  it  a  separate  non-virtualized  machine.  On  the  other  hand,  the 
backend  servers,  which  we  use  as  game  servers,  run  on  a  virtualized  environment  called 
Vmware  ESXi. 
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10.0.0.3  -  vSphere  Client 


Home 


|  Inventory  >  ^  Inventory 


]  10.0.0.3 

^  BACKHAND 
BACKTRACK 
^  FOREHAND 


bcalhost.loca (domain  VMware  ESXi,  5.1.0, 1065491  |  Evaluation  (15  days  remaining) 
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Configuration  Issues 

ESXi  Shell  for  the  host  has  been  enabled 
SSH  for  the  host  has  been  enabled 


General 


Manufacturer: 

Model: 

CPU  Cores: 

Processor  Type: 

License: 

Processor  Sockets: 

Cores  per  Socket: 

Logical  Processors: 
Hyperthreading: 

Number  of  NICs: 

State: 

Virtual  Machines  and  Templates: 
vMotion  Enabled: 


Dell  Inc. 

PowerEdge  1950 
8  CPUs  x  2.66  GHz 
In  tel  (R)  Xeon(R)  CPU 
X5355  @  2.66GHz 
Evaluation  Mode  - 


Inactive 

2 

Connected 

3 

N/A 


Resources 


CPU  usage:  50  MHz 
Memory  usage:  4483.00  MB 


Capacity 
8x2.66  GHz 
Capacity 
16378.87  MB 


Storage 

datastorel 


Network 

£  VM  Network 


Capacity 
460.75  GB 


Type 

Standard  port  group 


Fault  Tolerance 


Name,  Target  or  Status  contains:  ▼ 


Figure  14.  VMware  ESXi  vSphere  Client. 


We  used  VMware  ESXi  as  the  bare -metal  operating  system  to  virtualize  the  game 
servers  and  to  make  the  network  more  efficient.  As  DISA  STIG  about  VMware  ESXi  5 
requests,  we  installed  and  maintained  the  server  and  database  operating  systems  through 
ESXi  shell  and  the  software  called  vSphere  Client  (Figure  14). 

In  this  process  the  usage  of  ESXi  shell  was  very  helpful  because  it  can  be 
managed  by  connecting  through  a  secure  shell  (Figure  15).  ESXi  shell  is  useful  because  it 
does  not  need  a  direct  connection  with  the  ESXi  virtualization  server.  It  is  enough  to  have 
a  remote  connection  to  reverse  proxy  and  use  secure  shell  to  access  the  virtualization 
server. 
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0  O  O  wg  —  root@BACKHAND:/var/www/html  —  ssh  —  80x24 


sh-3.2#  ssh  -1  root  10.0.0.3 
Password: 

The  time  and  date  of  this  login  have  been  sent  to  the  system  logs. 

VMware  offers  supported,  powerful  system  administration  tools.  Please 
see  www.vmware.com/go/sysadmintools  for  details. 

The  ESX1  Shell  can  be  disabled  by  an  administrative  user.  See  the 
vSphere  Security  documentation  for  more  Information. 

~  # 


Figure  15.  VMware  ESXi  command  shell. 


VIRTUALIZED  SYSTEMS  ON  CSFV  NETWORK 

VM 

NAME 

ROLE 

HOSTNAME 

IP  ADDRESS 

OPERATING  SYSTEM 

ESXi  1 

WEB  SERVER 

csfv5 

10.0.0.234 

RED  HAT  ENTERPRISE 

LINUX  6.4 

ESXi  1 

WEB  SERVER 

csfv6 

10.0.0.235 

RED  HAT  ENTERPRISE 

LINUX  6.4 

ESXi  2 

IDS  -  1 

swing 

10.0.0.236 

RED  HAT  ENTERPRISE 

LINUX  6.4 

ESXi  3 

DATABASE  SERVER 

and  IDS-2 

csfv7 

192.168.0.11 

RED  HAT  ENTERPRISE 

LINUX  6.4 

Table  2.  Virtualized  systems. 


As  it  is  seen  from  the  Table  2,  there  are  three  bare-metal  virtualization  operating 
systems  in  the  network.  ESXi-2  runs  the  game  servers  at  10.0.0.0  network,  ESXi-1  runs 
the  first  IDS  server  at  10.0.0.0  network  and  ESXi-3  runs  the  database  server  and  the 
second  IDS  server  at  192.168.0.0  network. 

The  non-virtualized  systems  (Table  3)  consist  of  a  reverse  proxy  server  and 
firewall  server,  which  run  on  the  CentOS  6.4  operating  system.  They  use  CentOS  because 
the  first  CSFV  systems,  which  would  run  on  Amazon  cloud  architecture,  EC2,  would 
have  CentOS  as  a  server  operating  system.  CentOS  shares  the  same  source  code  as  Red 
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Hat,  and  the  main  difference  between  them  is  that  the  necessary  update  packages  are 
publicly  open  source  (Red  Hat  Enterprise  Linux  Installation  Guide,  2013). 


NON-VIRTUALIZED  SYSTEMS  ON  CSFV  NETWORK 

ROLE 

HOSTNAME 

IP  ADDRESS 

OPERATING  SYSTEM 

REVERSE  PROXY + 

FIREWALL 

csfv4 

172.20.104.233 

CENTOS  6.4 

FIREWALL-2 

second 

chance 

10.0.0.21 

CENTOS  6.4 

Table  3.  Non- virtualized  Systems. 


Additionally,  we  downloaded  and  installed  the  necessary  software  packages  from 
Red  Hat  repository  to  run  the  games  appropriately.  The  necessary  coordination  was  done 
with  the  contactor  from  TopCoder  (CSFV  PI  Meeting,  2013).  In  total,  16  packages  are 
displayed  in  this  chapter,  and  they  are  installed  particularly  to  run  the  games.  The 
remaining  422  packages,  which  are  necessary  for  any  other  Linux  box,  are  shown  in  the 
Appendix. 
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collectd.x86  64 

4.10.9-1. el6 

@epel 

epel-release . noarch 

6-8 

@epel 

gccxml.x86  64 

0. 9. 0-0. 12. 2 012 03  0 9  . el6 

@epel 

ius-release . noarch 

1.0-11. ius . el6 

@  ius 

joe .x86_64 

3.7-4 . el6 

@epel 

kernel. x86  6 

2.6.32- 

220.17.1.el6 .centos .plus 

@centosplus 

kernel. x86  64 

2.6.32- 

358.6.1.el6. centos . plus 

@centosplus 

kernel-devel . x8 6  64 

2.6.32- 

220.17.1.el6 .centos .plus 

@centosplus 

kernel-devel . x8 6  64 

2.6.32- 

358.6.1.el6. centos . plus 

@centosplus 

kernel- 

firmware  . noarch 

2.6.32- 

358.6.1.el6. centos . plus 

@centosplus 

kernel- 

headers.  x86  64 

2.6.32- 

358.6.1.el6. centos . plus 

@centosplus 

links. x86  64 

1:2. 2-12. el6 

@epel 

mongo-10gen.x86  64 

2 . 4 . 3-mongodb  1 

@ lOgen 

mongo-1 Ogen- 
server.x86  64 

2 . 4 . 3-mongodb  1 

@  lOgen 

nginx.x86  64 

1 . 4 . 1-1 . el6 . ngx 

@nginx 

xmlstarlet . x8 6  64 

1.3 . 1-1. el6 

@epel 

Table  4.  Necessary  packages  from  CentOS  repository 


3.  Running  Firewall  Rules 

The  CSFV  network  uses  the  Linux  IPtables  application  that  is  embedded  on  the 
Red  Hat/CentOS  operating  systems  to  define  firewall  rules  for  the  firewall  servers.  We 
chose  to  use  the  Linux  IPtables  feature  because  it  does  not  need  any  additional  hardware 
or  software,  which  would  incur  additional  cost;  it  is  a  powerful  tool  used  world-wide,  and 
it  is  flexible  enough  to  give  the  system  administrator  a  wide  area  of  rule  options. 

IPtables  operates  by  using  the  “TABLE”  concept,  which  has  “CHAINs”.  The  two 
main  tables  are  “NAT”  and  “FILTER.”  The  NAT  table  has  PREROUTING, 
POSTROUTING  and  OUTPUT  chains.  On  the  other  hand,  the  FILTER  table  includes 
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INPUT,  OUTPUT  and  FORWARD  chains.  IPtables  also  has  the  feature  of  user-defined 
rules. 


Our  IPtables  rules  include  two  tables.  The  “NAT”  table  provides  the  network  with 
Network  Address  Translation  (NAT)  to  access  outside  of  the  network.  It  is  also  a  tool  to 
enhance  security  and  availability  of  the  network.  The  NAT  rules  make  the  servers  inside 
our  network  access  the  IP  range  outside  of  the  CSFV  network  by  getting  different  IP 
addresses. 

The  FILTER  table  does  most  of  the  work  in  the  network.  It  accepts  certain  IP 
addresses  and  ports,  drops  unwanted  IP  traffic  for  security  or  performance  reasons  and 
logs  the  IP  packets,  which  were  dropped  for  further  inspection. 

Our  first  firewall  (csfv4.ern.nps.edu)  has  the  rules  to  accept  incoming  valid 
packets.  It  is  set  to  allow  the  incoming  traffic  to  the  server’s  22  and  443  ports. 

-A  INPUT  -s  0/0  -i  ethO  -d  172.20.104.233  -p  TCP  — dport 

443  -j  ACCEPT 

-A  INPUT  -s  0/0  -i  ethO  -d  172.20.104.233  -p  TCP  — dport 

22  -j  ACCEPT 

-A  INPUT  -p  icmp  -j  ACCEPT 

-A  INPUT  -p  top  -m  state  — state  RELATED , ESTABLISHED  -j 

ACCEPT 

-A  OUTPUT  -s  172.20.104.233  -o  ethO  -d  0/0  -p  top  — sport 

22  -j  ACCEPT 

-A  OUTPUT  -p  top  -m  state  — state  NEW, RELATED , ESTABLISHED  - 
j  ACCEPT 

-A  FORWARD  -p  top  -m  state  — state  RELATED, ESTABLISHED  -j 
ACCEPT 

-A  FORWARD  -p  top  — dport  22  -m  state  — state 

RELATED, ESTABLISHED  -j  ACCEPT 
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Csfv4.ern.nps.edu  has  the  rules  to  drop  the  invalid  packets,  spoofed  packets, 
XMAS  scan  packets  and  NULL  scan  packets,  which  are  techniques  for  port  scanning. 

-A  INPUT  -m  state  — state  INVALID  -j  DROP 
-A  FORWARD  -m  state  — state  INVALID  -j  DROP 
-A  OUTPUT  -m  state  — state  INVALID  -j  DROP 

-A  INPUT  -s  10.0.0.0/24  -i  ethO  -d  172.20.104.233  -p  tcp  - 
j  DROP 

-A  INPUT  -s  192.168.0.0/24  -i  ethO  -d  172.20.104.233  -p 

tcp  -j  DROP 

-A  INPUT  -s  10.0.0.0/24  -1  ethO  -d  172.20.104.233  -p  udp  - 
j  DROP 

-A  INPUT  -s  192.168.0.0/24  -i  ethO  -d  172.20.104.233  -p 

udp  -j  DROP 

-A  INPUT  -p  tcp  — tcp-flags  ALL  ALL  -j  DROP 

-A  INPUT  -p  tcp  — tcp-flags  ALL  NONE  -j  DROP 


We  used  also  DROP  policies  to  define  a  default  rule  for  packets. 


-P  INPUT  DROP 
-P  OUTPUT  DROP 
-P  FORWARD  DROP 

For  logging  dropped  packages: 

-A  INPUT  -m  limit  — limit  15 /minute  -j  LOG  — log-level  4  — 
log-prefix  "DROPPED  PACKETS_FIRUZ :  " 
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The  second  firewall,  “Second  Chance,”  has  the  rules  for  allowing  the  traffic 
between  the  game  servers  and  the  database  server  and  drop  else. 


Rules  to  accept  necessary  packets: 


-A  INPUT  -s  10.0.0.1  -i  ethO  -d  10.0.0.21  -p  TCP  — dport 
22  -j  ACCEPT 

-A  OUTPUT  -s  10.0.0.21  -o  ethO  -d  10.0.0.1  -p  tcp  — sport 
22  -j  ACCEPT 

-A  OUTPUT  -s  10.0.0.21  -o  ethl  -d  192.168.0.11  -p  TCP  — 
sport  22  -j  ACCEPT 


-A  INPUT  -s  192.168.0.11  -i  ethl  -d  10.0.0.21  -p  tcp  — 
dport  22  -j  ACCEPT 

-A  INPUT  -p  tcp  -m  state  — state  RELATED ,  ESTABLISHED  -j 
ACCEPT 

-A  OUTPUT  -p  tcp  -m  state  — state  NEW, RELATED , ESTABLISHED  - 
j  ACCEPT 


-A  FORWARD  -p  tcp  -m  state  — state  RELATED, ESTABLISHED  -j 
ACCEPT 

-A  FORWARD  -p  tcp  --dport  22  -m  state  — state 
RELATED, ESTABLISHED  -j  ACCEPT 

-A  FORWARD  -s  10.0.0.234  -d  192.168.0.11  -p  tcp  --dport 

27017  -m  state  — state  RELATED, ESTABLISHED  -j  ACCEPT 
-A  FORWARD  -s  10.0.0.235  -d  192.168.0.11  -p  tcp  --dport 

27017  -m  state  — state  RELATED, ESTABLISHED  -j  ACCEPT 
-A  INPUT  -p  icmp  -j  ACCEPT 
-A  OUTPUT  -p  icmp  -j  ACCEPT 


The  rule  to  log  malicious  or  unnecessary  traffic: 

-A  INPUT  -m  limit  — limit  15/minute  -j  LOG  — log-level  4  — 
log-prefix  "DROPPED  PACKETS_FIRUZ :  " 

Rules  to  drop  invalid  packets: 

-A  INPUT  -m  state  — state  INVALID  -j  DROP 
-A  FORWARD  -m  state  — state  INVALID  -j  DROP 
-A  OUTPUT  -m  state  — state  INVALID  -j  DROP 
-P  INPUT  DROP 
-P  OUTPUT  DROP 
-P  FORWARD  DROP 

4.  Reverse  Proxy  Deployment 

As  mentioned  previously,  the  reverse  proxy  is  implemented  outside  of  the 
10.0.0.0  network.  It  is  done  this  way  to  provide  more  security  by  letting  game  servers 
stay  on  a  subnet  other  than  the  reverse  proxy. 
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An  Apache  web  server  was  configured  to  provide  the  reverse  proxy  function. 
When  a  user  types  “csfv4.ern.nps.edu”  in  his  browser,  our  web  server  directs  this  request 
to  one  of  the  game  servers  and  gathers  the  data  by  load  balancing  the  user  requests. 

The  Apache  configuration  rules,  which  reside  at  /var/httpd/conf/httpd.conf,  enable 

the  Apache  server  to  transfer  the  files  from  game  servers  to  the  users  and  to  load  balance 

the  requests.  We  added  these  rules  to  the  configuration  file  of  Apache  on 

csfv4.ern.nps.edu: 

<If Module  mod_proxy . c> 

ProxyRequests  Off 
<Proxy  *> 

Order  deny , allow 
Allow  from  all 
</Proxy> 

#The  name  of  the  load  balancer  is  "mycluster  "which  will 
#distribute  all  requests  between  10.0.0.234  and  10.0.0.235 
<Proxy  balancer : //myc lust er> 

BalancerMember  http: //I 0.0.0. 234 : 80 
BalancerMember  http: //I 0.0.0. 235 : 80 
< /Proxy > 

ProxyPass  /  balancer : //mycluster 

ProxyPreserveHost  On 

ProxyVia  On 

SSLProxyEngine  on 

ProxyPass  /  http: / / 10 . 0 . 0 . 234 : 80 

ProxyPass  /  http: //10 . 0 . 0 . 235 : 80 

ProxyPassReverse  /  http : / / 10 . 0 . 0 . 234 : 80 

ProxyPassReverse  /  http: //10 . 0 . 0 . 235 : 80 

5.  IDS  Deployment 

As  we  mentioned  earlier,  firewall  rules  will  operate  at  layer  4,  inspecting  the 
socket  pairs.  Because  we  did  not  use  a  deep  packet  inspection  firewall  to  inspect  the 
packet  traffic  at  the  application  level,  we  should  use  an  IDS  device  to  watch  the  traffic 
above  layer  4.  We  chose  Snort  as  our  network  monitoring  and  IDS  solution. 

Snort  is  an  open  source  tool,  which  can  serve  as  a  sniffer,  logger  or  a  network- 
based  intrusion  detection  system.  There  are  many  organizations  around  the  world  that  use 
SNORT  for  intrusion  detection.  It  is  also  used  for  protecting  the  DREN  network  on  the 
NPS  campus. 
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Snort  has  some  rule  sets  as  the  default.  In  addition,  other  necessary  packages  can 
be  installed  or  user-defined  packages  can  be  created  (Alder,  2004).  We  used  Snort’s 
predefined  packages  for  the  CSFV  network.  Being  deployed  both  on  the  10.0.0.0  subnet 
and  192.168.0.0  subnet,  Snort  will  use  a  wide  range  of  rule  sets  to  detect  malicious 
traffic,  some  of  which  are  bad  data  traffic,  exploits  about  mysql,  sql  injection,  web 
attacks,  DDoS,  flash,  chat  and  browser  vulnerabilities.  The  Snort  rules  on  CSFV  network 
include: 

#  include  $SO_RULE_PATH/bad-traf fic . rules 

#  include  $ SO_RULE_PATH/ chat . rules 

#  include  $SO_RULE_PATH/dos . rules 

#  include  $ SO_RULE_PATH/ exploit . rules 

#  include  $SO_RULE_PATH/icmp . rules 

#  include  $SO_RULE_PATH/imap . rules 

#  include  $SO_RULE_PATH/misc . rules 

#  include  $SO_RULE_PATH /multimedia . rules 

#  include  $SO_RULE_PATH/netbios . rules 

#  include  $SO_RULE_PATH/nntp . rules 

#  include  $S0_RULE_PATH/p2p . rules 

#  include  $SO_RULE_PATH/smtp . rules 

#  include  $SO_RULE_PATH/snmp . rules 

#  include  $SO_RULE_PATH/specif ic-threats . rules 

#  include  $SO_RULE_PATH/web-activex . rules 

#  include  $SO_RULE_PATH/web-client . rules 

#  include  $SO_RULE_PATH/web-iis . rules 

#  include  $SO_RULE_PATH/web-misc . rules 


6.  Data  Encryption 

Data  encryption  is  implemented  for  the  data  in  motion  on  the  CSFV  network.  As 
previously  stated  SSL  protocol  is  used  to  encrypt  the  data  flowing  between  the  game 
players  and  the  reverse  proxy  server.  Because  port  80  would  be  closed  on  the  firewall  of 
csfv4.ern.nps.edu,  all  data  traffic  would  go  through  port  443,  which  is  used  by  HTTPS. 
The  data  traffic  on  the  CSFV  network,  however,  will  be  unencrypted  going  through  port 
80.  Here,  the  idea  is  that  if  we  encrypt  the  moving  data  inside  the  network  it  needs  to  be 
decrypted  on  the  reverse  proxy  server,  re-encrypted  and  served  to  the  clients.  If  a 
malicious  user  can  get  to  the  reverse  proxy  server  as  the  man-in-the-middle  he  can  also 
process  the  data,  and  the  security  would  be  worthless  (Kew,  2003).  Thus;  we  use  SSL 
encryption  between  clients  and  the  reverse  proxy  server. 
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The  necessary  SSL  module  (mod  ssl)  for  the  CentOS  operating  system  to  encrypt 
the  data  traffic  was  downloaded  from  the  CentOS  repository  (Figure  16).  It  runs  as  an 
Apache  httpd  module  dependent. 


0  O  O  wg  —  root@csfv4: - ssh  —  83x40 


Instalted  Packages 
Name  :  mod_sst 

Arch  :  x86_64 

Epoch  :  1 

Version  :  2.2.15 

Release  :  28. e!6. centos 

Size  :  183  k 

Repo  :  Installed 

From  repo  :  updates 

Summary  :  SSL/TLS  module  for  the  Apache  HTTP  Server 

URL  :  http://httpd.apache.org/ 

License  :  ASL  2.0 

Description  :  The  mod_ssl  module  provides  strong  cryptography  for  the  Apache  Web 

:  server  via  the  Secure  Sockets  Layer  (SSL)  and  Transport  Layer 
:  Security  (TLS)  protocols. 

[root@csfv4  -]# 


Figure  16.  The  SSL  module  for  CentOS  . 


7.  System  Validation  via  Penetration  Testing  Tools 

To  test  the  capability  of  Snort,  we  directed  some  attacks  on  the  10.0.0.0  subnet. 
The  first  attack  tool  we  used  is  Nmap,  which  is  widely  used  to  map  networks  by  scanning 
ports  and  gathering  port  information.  We  scanned  the  10.0.0.0  network  range  with  Nmap 
and  triggered  Snort. 

The  second  tool  we  used  to  test  Snort  is  Low  Orbit  Ion  Cannon  (LOIC).  This  tool 
sends  thousands  of  tcp,  udp  or  http  packets  to  make  DDoS  attacks  on  specific  IP 
addresses  or  web  sites.  It  is  widely  used  on  Internet  to  attack  targets. 

We  used  LOIC  to  perfonn  attacks  on  the  second  game  server’s  (csfv6- 
10.0.0.235)  port  80  using  udp  packets  (Figure  17).  This  attack  is  also  caught  by  Snort 
(Table  5). 
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Low  Orbit  Ion  Cannon  |  When  harpoons,  air  strikes  and  nukes  fails  |  v.  1. 0.7,0 


1.  Select  your  target  - 


IMMACHARGIN  MAH  LAZER 


10.0.0.235 


Timeout 

9001 


TCP  /UDP  message 

A  cat  is  fine  too.  Desudesudesu' 


80  |  UDP 


1000  Jj  Wal  for  reply 


Port 

Method  Threads 

<=  taster  Speed  slower  => 

Idle 

Connecting  Requesting 

Downloading 

Downloaded  Requested 

Failed 

Figure  17.  Attacking  on  the  game  server  via  LOIC. 
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SNORT  ALERTS 

1 

[**]  [1:100000160:2]  COMMUNITY  SIP  TCP/IP  message 

flooding  directed  to  SIP  proxy  [**] 

[Classification:  Attempted  Denial  of  Service] 

[Priority:  2] 

08/04-04:54:48.095433  10.0.0.235:593  -> 

10.0.0.51:34225 

TCP  TTL:64  TOS:0x0  ID:0  IpLen:20  DgmLen:40  DF 
*  *  *a*r*  *  Seq:  0x0  Ack:  0xF97CB988  Win:  0x0  TcpLen:  20 

2 

[**]  [1:100000160:2]  COMMUNITY  SIP  TCP/IP  message 

flooding  directed  to  SIP  proxy  [**] 

[Classification:  Attempted  Denial  of  Service] 

[Priority:  2] 

08/04-04:54:48.095960  10.0.0.51:34225  -> 

10.0.0.235:1084 

TCP  TTL : 5 5  TOS:0x0  ID:23251  IpLen:20  DgmLen:44 
******S*  Seq:  0xF97CB987  Ack:  0x0  Win:  0x400 

TcpLen:  24 

TCP  Options  (1)  =>  MSS:  1460 

3 

[**]  [116:59:1]  ( snort_decoder ) :  Top  Window  Scale 

Option  found  with  length  >  14  [**] 

[Priority:  3] 

08/04-04:54:49.016109  10.0.0.51:60511  ->  10.0.0.235:1 

TCP  TTL : 5 2  TOS:0x0  ID:51460  IpLen:20  DgmLen:60 
**U*p**F  seq:  0x6BC901C6  Ack:  0xBAB16756  Win:  OxFFFF 
TcpLen:  40  UrgPtr:  0x0 

TCP  Options  (5)  =>  WS :  15  NOP  MSS:  265  TS :  4294967295  0 

SackOK 

4 

[**]  [122:1:0]  (portscan)  TCP  Portscan  [**] 

[Priority:  3] 

08/04-04:55:44.906805  10.0.0.51  ->  10.0.0.2 

PROTO : 255  TTL : 0  TOS:0x0  ID:27082  IpLen:20  DgmLen:160 
DF 

5 

[**]  [1:100000160:2]  COMMUNITY  SIP  TCP/IP  message 

flooding  directed  to  SIP  proxy  [**] 

[Classification:  Attempted  Denial  of  Service] 

[Priority:  2] 

08/04-04:55:47.361994  10.0.0.51:40883  -> 

10.0.0.21:49157 

TCP  TTL: 53  TOS:0x0  ID: 5 9640  IpLen:20  DgmLen:44 
******S*  Seq:  0x4ClBBD2  Ack:  0x0  Win:  0x400  TcpLen: 
24 

TCP  Options  (1)  =>  MSS:  1460 

Table  5.  SNORT  alerts 
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V.  CONCLUSION 


A.  SUMMARY  AND  CONCLUSION 

Manual  formal  software  verification  is  an  expensive  and  time-consuming  process. 
The  verification  of  military  software  is  currently  performed  by  highly  skilled  analysts 
(Dean,  2013).  To  reduce  the  high  costs  of  the  formal  verification,  DARPA  started  a 
Crowd-Sourced  Formal  Verification  (CSFV)  program  in  2011.  The  goal  of  the  program 
is  to  encourage  as  many  people  as  possible  to  participate  in  this  verification  process  by 
embedding  some  of  the  verification  logics  into  computer  games  that  are  fun  to  play. 

In  this  study  the  CSFV  network  is  designed  and  implemented  according  to  the 
common  security  practices,  necessary  security  measures  against  possible  attacks,  and 
DISA  STIGs  to  configure  network  components.  After  validation  and  verification  steps  we 
observe  that  the  system  is  working  well  with  all  its  security  elements,  and  it  can  be 
trusted  to  deploy  on  a  secure  DoD  network.  We  recommend  that  the  DoD  install  and 
experiment  with  our  CSFV  network  prototype  on  its  systems. 

The  main  goal  of  this  thesis  study  is  to  design  and  prototype  a  secure  and  robust 
infrastructure  for  CSFV  games.  After  going  through  a  review  of  the  literature  and 
carrying  out  the  design  and  implementation  steps,  we  conclude  that  our  CSFV  system 
prototype  provides  these  key  features: 

IP  address  filtering  and  NAT:  Our  CSFV  system  prototype  provides  IP  address 
and  port  filtering  with  its  firewall  servers.  First  firewall  rules  are  set  to  prevent  network 
attacks  by  dropping  spoofed,  invalid  and  malicious  packets,  such  as  XMAS  and  NULL 
scan  packets.  Also  the  first  firewall  logs  those  malicious  packets.  Furthermore  this 
firewall  server  provides  network  address  translation  rules  to  use  a  different  set  of  IP 
addresses  from  those  used  by  the  external  network.  Our  second  firewall,  on  the  other 
hand,  allows  communication  only  between  the  game  servers  and  the  database  server.  This 
firewall  provides  a  NAT  solution  as  well. 

Network  monitoring  and  intrusion  detection:  We  implemented  SNORT  as  an 
IDS  on  both  10.0.0.0  and  192.168.0.0  subnets  to  monitor  the  network  activity.  SNORT 
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uses  a  wide  range  of  rule  sets  to  detect  malicious  traffic,  including  sql  injection,  web 
attacks,  DDoS,  flash,  and  browser  vulnerabilities.  In  Chapter  IV  we  tested  the  network 
security  levels  with  common  attack/scan  tools. 

Further  security  for  game  servers  with  a  reverse  proxy  server:  By  deploying  a 
reverse  proxy  server  outside  the  CSFV  network,  we  aimed  to  avoid  direct  communication 
between  game  players  and  the  CSFV  game  servers.  In  our  CSFV  network  prototype  the 
reverse  proxy  server  hands  over  the  data  from  the  game  servers  to  the  game  players.  In 
this  way  we  tried  to  reduce  the  risk  of  compromise  of  any  game  servers.  The  reverse 
proxy  also  load  balanced  the  game  servers  depending  on  the  number  of  game  players. 

Secure  data  transfer  over  SSL:  All  the  game  data  flowing  between  the  reverse 
proxy  server  and  game  players  are  encrypted  by  the  SSL  protocol,  and  they  use  port  443. 

B.  FUTURE  WORK  AND  CONSIDERATIONS 

This  section  presents  further  methods  of  increasing  the  security  levels  of  the 
CSFV  network  prototype: 

•  Currently  game  servers  on  the  CSFV  network  are  kept  on  the  same  subnet 
for  the  sake  of  network  performance  and  simplicity.  However,  to  provide 
even  more  security,  each  game  server  can  be  placed  in  separate  subnets  to 
prevent  simultaneous  compromise  of  the  game  servers. 

•  There  is  a  single  database  to  store  both  game  data  and  user  data.  A 
separate  database  can  be  designated  only  for  user  data  to  create  another 
security  layer  for  user  privacy.  Game  data  would  then  stay  on  a  different 
database. 

•  Network  based  attacks  can  be  augmented  including  social  engineering 
attacks  and  other  network  penetration  tools. 

•  Alternative  scenarios  can  be  created  to  isolate  game  servers  from  the 
reverse  proxy  in  case  of  a  compromise  of  the  reverse  proxy  server. 
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APPENDIX 


The  Necessary  Yum  Packages  to  Run  CSFV  Games: 


MAKEDEV . x8  6_6  4 
abrt . x86_64 

abrt-addon-kerneloops . x86_64 

abrt- libs . x86_64 

acl . x86_64 

alsa-lib . x86_64 

apr-util . x86_64 

audit- libs . x86_64 

atk . x86_64 

autoconf . noarch 

automake . noarch 

avahi-libs . x86_64 

basesystem. noarch 

bash . x86_64 

be . x86_64 

binut ils . x86_64 

bison . x86_64 

btparser . x86_64 

bzip2 . x86_64 

bzip2-libs .x86_64 

ca-certif icates . noarch 

cairo . x86_64 

cdparanoia-libs . x86_64 

centos-indexhtml . noarch 

centos -release . x86_64 

checkpolicy . x86_64 

chkconf ig . x86_64 

cloog-ppl . x86_64 

compat-gcc-34 .x86_64 

compat-gcc-34-g77 .x86_64 

compat-libf 2c-34 .x86_64 

compat-libstdc++-296 . i686 

compat-readline5 . x86_64 

cpio . x86_64 

epp . x86_64 

cracklib . x86_64 

cracklib-dicts . x86_64 

createrepo . noarch 

cronie . x86_64 

cronie-anacron . x86_64 

crontabs . noarch 

evs . x86_64 

cyrus -s as 1 . x86_64 

cyrus -s as 1- lib . x86_64 

dash . x86_64 

db4 . x86_64 

db4 -utils . x86_64 

dbus . x86_64 

dbus-libs . x86_64 

de j  avu-f onts-common . noarch 

de javu-lgc-sans-mono-f onts . noarch 

de javu-sans-mono-f onts . noarch 

deltarpm. x86_64 

device-mapper . x86_64 

device-mapper-event . x8  6_6  4 

device-mapper-event-libs . x86_64 

device-mapper-libs . x86_64 

device-mapper-multipath . x86_64 

device-mapper-multipath-libs . x86_64 

device-mapper-persistent-data . x86_64 

dhclient . x86_64 

dhcp-common . x8  6_6  4 


3.24-6. el6 

@base 

2.0. 8-15. el6. centos 

@base 

2.0. 8-15. el6. centos 

@base 

2.0. 8-15. el6. centos 

@base 

2.2. 49-6 . el6 

@base 

1.0. 22-3. el6 

@base 

1 . 3 . 9-3 . el6  0.1 

@base 

2.2-2. el6 

@base 

1.28. 0-2. el6 

@base 

2 . 63-5 . 1 . el6 

@base 

1.11. 1-4 ,el6 

@base 

0.6. 25-12. el6 

@base 

10 . 0-4 . el6 

@base 

4.1. 2-14. el6 

@base 

1.06. 95-1. el6 

@base 

2. 20. 51. 0.2-5. 36. el6 

@base 

2.4. 1-5 .el6 

@base 

0 . 17-1 ,el6 

@base 

1 . 0 . 5-7 . el6  0 

@base 

1 . 0 . 5-7 . el6  0 

@base 

2010. 63-3. el6  1.5 

@base 

1.8. 8-3 . 1 .el6 

@base 

10.2-5.1. el6 

@base 

6-1 . el6 . centos 

@base 

6-4 . el 6 . centos . 10 

@base 

2.0. 22-1. el6 

@base 

1.3.49. 3-2 .el6 

@base 

0.15.7-1.2 .el6 

@base 

3.4.6-19. el6 

@base 

3.4.6-19. el6 

@base 

3.4.6-19. el6 

@base 

2. 96-144. el6 

@base 

5.2-17.1. el6 

@base 

2 . 10-11 .el6  3 

@base 

4.4. 7-3 .el6 

@base 

2.8.16-4. el6 

@base 

2.8.16-4. el6 

@base 

0.9. 9-17. el6 

@base 

1.4. 4-7 .el6 

@base 

1.4. 4-7 .el6 

@base 

1 . 10-33 .el6 

@base 

1.11. 23-15. el6 

@base 

2.1. 23-13. el6  3.1 

@base 

2.1. 23-13. el6  3.1 

@base 

0.5.5. 1-4 .el6 

@base 

4.7.25-17. el6 

@base 

4.7.25-17. el6 

@base 

1:1.2. 24-7 . el6  3 

@base 

1:1.2.24-7. el6  3 

@base 

2 . 30-2 . el6 

@base 

2 . 30-2 . el6 

@base 

2 . 30-2 . el6 

@base 

3 . 5-0 . 5 . 200909 13git . el6 

@base 

1.02. 77-9. el6 

@base 

1.02. 77-9. el6 

@base 

1.02. 77-9. el6 

@base 

1.02. 77-9. el6 

@base 

0.4. 9-64. el6 

@base 

0.4. 9-64. el6 

@base 

0.1. 4-1 .el6 

@base 

12:4. 1.1-34. PI. el6. centos 

@base 

12:4. 1.1-34. PI. el6. centos 
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@base 

diff utils . x86_64 

dmraid . x8  6_6 4 

dmraid-events . x86_64 

dracut . noarch 

dracut-kernel . noarch 

e2f sprogs . x86_64 

e2f sprogs-libs .x86_64 

ec j . x86_64 

ed . x86_64 

elf utils . x86_64 

elf utils- libel f . x86_64 

elf utils -libs . x86_64 

ethtool . x86_64 

file . x86_64 

file-libs .x86_64 

f ilesystem. x86_64 

f indutils . x86_64 

f ipscheck . x86_64 

f ipscheck-lib . x86_64 

flex . x86_64 

f ontconf ig . x86_64 

fontpackages-f ilesystem. noarch 

f oomatic . x8  6_6  4 

f oomatic-db . noarch 

foomatic-db-f ilesystem. noarch 

f oomatic-db-ppds . noarch 

gamin . x86_64 

gawk . x86_64 

gcc . x86_64 

gcc-c++ . x86_64 

gcc-gf ortran . x86_64 

gcc-gnat . x86_64 

gcc- java . x86_64 

gcc-ob jc . x86_64 

gcc-ob j C++ . x86_64 

gdb . x86_64 

gdbm. x86_64 

gettext . x8  6_6  4 

ghostscript-f onts . noarch 

glib2 . x86_64 

glibc . i686 

glibc . x86_64 

glibc-common . x86_64 

glibc-devel . x86_64 

glibc -headers . x86_64 

gnupg2 .x86_64 

gpgme . x86_64 

gpm-libs . x86_64 

grep . x86_64 

grof f . x86_64 

grubby . x8  6_6  4 

gstreamer . x86_64 

gstreamer-plugins-base . x86_64 

gstreamer-tools . x86_64 

gtk2 . x86_64 

gzip . x86_64 

hicolor-icon-theme . noarch 

hwdata . noarch 

info . x86_64 

iproute . x86_64 

iptables . x86_64 

iputils . x86_64 

iso-codes . noarch 

java-1 . 5 . 0-gc j . x86_64 

j  ava_cup . x8  6_6  4 

jpackage-utils . noarch 

kbd . x86_64 

kbd-misc . noarch 

keyutils-libs . x86_64 

kpartx . x8  6_6  4 

lcms-libs . x86  64 


2.8. 1- 28. el6 
1.0.0.rcl6-ll.el6 
1.0.0.rcl6-ll.el6 
004-303. el6 
004-303. el6 

1.41. 12-14. el6 

1.41. 12- 14. el6 
1:3.4. 2-6 . el6 

1.1- 3. 3. el6 
0. 152-1. el6 
0. 152-1. el6 
0. 152-1. el6 
2:3. 5-1 . el6 
5 . 04-15 . el6 
5.04-15. el6 
2.4. 30-3 . el6 
1:4.4. 2-6 . el6 
1.2. 0-7 . el6 
1.2. 0-7 . el6 
2.5. 35-8 . el6 
2.8. 0-3 . el6 
1.41-1. I.el6 

4 . 0 . 4-1 . el6_l . 1 
4. 0-7. 20091126. el6 
4. 0-7. 20091126. el6 
4. 0-7. 20091126. el6 
0.1. 10-9. el6 

3.1. 7- 10. el6 

4.4. 7- 3 . el6 

4.4. 7-3 . el6 

4.4. 7-3 . el6 

4.4. 7-3 . el6 

4.4. 7-3 . el6 

4.4. 7-3 . el6 

4.4. 7- 3 . el6 

7.2- 60. el6 
1.8. 0-36. el6 
0. 17-16. el6 
5.50-23. I.el6 

2.22. 5- 7 . el6 

2.12- 1.107. el6 

2.12-1.107. el6 

2.12-1.107. el6 

2.12-1.107. el6 

2.12- 1.107. el6 
2.0. 14-4. el6 

1.1. 8- 3 . el6 

1.20. 6- 12. el6 
2.6. 3-3 . el6 

1.18.1. 4- 21. el6 
7.0. 15-3. el6 
0.10. 29-1. el6 
0.10. 29-2. el6 
0.10. 29-1. el6 
2.18.9-12. el6 

1.3. 12- 18. el6 
0.11-1.1. el6 
0.233-7. 9. el6 
4 . 13a-8 . el6 
2.6. 32-23 . el6 
1.4. 7-9 . el6 
20071127-16. el6 
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libXf ont . x86_64 

libXf t . x86_64 

libXi . x86_64 

libXinerama . x86_64 

libXrandr . x86_64 

libXrender . x86_64 

libXt . x86_64 
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libxslt . x86_64 
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lua . x86_64 

lvm2 . x86_64 
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mailcap . noarch 
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